[modifier] Release Branches / Les branches de publication
From a developer's point of view, a free software project is in a state of continuous release. Developers usually run the latest available code at all times, because they want to spot bugs, and because they follow the project closely enough to be able to stay away from currently unstable areas of the feature space. They often update their copy of the software every day, sometimes more than once a day, and when they check in a change, they can reasonably expect that every other developer will have it within 24 hours.
Du point de vue d'un développeur open-source, le projet se trouve dans un état permanent de finalisation. Les développeurs utilisent généralement le code le plus à jour pour y repérer les bogues et comme ils suivent le projet de suffisamment près, ils peuvent éviter les fonctionnalités encore instables. Il est courant pour eux de mettre à disposition une version quotidienne de leur logiciel, la mise à jour peut même être plus fréquente et lorsqu'ils publient une modification du code, ils estiment raisonnable d'attendre des autres développeurs qu'ils l'aient intégrée à leur version du logiciel dans les 24 heures qui suivent.
How, then, should the project make a formal release? Should it simply take a snapshot of the tree at a moment in time, package it up, and hand it to the world as, say, version « 3.5.0"? Common sense says no. First, there may be no moment in time when the entire development tree is clean and ready for release. Newly-started features could be lying around in various states of completion. Someone might have checked in a major change to fix a bug, but the change could be controversial and under debate at the moment the snapshot is taken. If so, it wouldn't work to simply delay the snapshot until the debate ends, because another, unrelated debate could start in the meantime, and then you'd have wait for that one to end too. This process is not guaranteed to halt.
Comment alors le projet doit-il s'y prendre pour proposer une version finalisée ? Doit-il se contenter d'utiliser une image de l'arborescence à un moment précis, de le packager et de l'offrir au monde en annonçant « voici la version 3.5.0 », par exemple ? Non évidemment ! D'abord, il se peut qu'à aucun moment l'arborescence de développement ne soit complètement propre et publiable. Des fonctionnalités dont le développement vient juste de commencer pourraient se trouver éparpillées à des états de finition différents. Quelqu'un pourrait avoir publié un correctif important pour un bogue précis, mais qui est controversé et encore débattu au moment où vous figez le programme. Si tel est le cas, repousser la livraison jusqu'à ce que le débat prenne fin n'aiderait en rien car un autre débat, pas forcément corrélé, pourrait naître entre temps et alors vous devriez également attendre la fin de ce dernier. Ce processus est potentiellement sans fin.
In any case, using full-tree snapshots for releases would interfere with ongoing development work, even if the tree could be put into a releasable state. Say this snapshot is going to be « 3.5.0"; presumably, the next snapshot would be « 3.5.1 », and would contain mostly fixes for bugs found in the 3.5.0 release. But if both are snapshots from the same tree, what are the developers supposed to do in the time between the two releases? They can't be adding new features; the compatibility guidelines prevent that. But not everyone will be enthusiastic about fixing bugs in the 3.5.0 code. Some people may have new features they're trying to complete, and will become irate if they are forced to choose between sitting idle and working on things they're not interested in, just because the project's release processes demand that the development tree remain unnaturally quiescent.
Dans tous les cas, figer l'arborescence entière entrerait forcement en conflit avec le développement en cours, même si l'arborescence courante était publiable. Si l'image courante de l'arborescence devient la version « 3.5.0 », l'image suivante, vraisemblablement la « 3.5.1 », contiendra principalement des correctifs des bogues introduits dans la version « 3.5.0 ».Mais si les deux sont des images de la même arborescence, que sont supposés faire les développeurs entre deux versions ? Ils n'ont pas l'autorisation d'ajouter de nouvelles fonctionnalités, les directives de compatibilité les en empêchent. Mais tout le monde n'est pas motivé par l'écriture de correctifs pour les bogues de la version 3.5.0. Certains pourraient désirer achever de nouvelles fonctionnalités et seraient irrités que la seule possibilité qu'on leur laisse est de choisir entre se tourner les pouces et travailler sur ce qui ne les intéresse pas simplement parce que le processus de publication du projet impose à l'arborescence de développement de rester dans un état de stabilité artificielle.
The solution to these problems is to always use a release branch. A release branch is just a branch in the version control system (see branch), on which the code destined for this release can be isolated from mainline development. The concept of release branches is certainly not original to free software; many commercial development organizations use them too. However, in commercial environments, release branches are sometimes considered a luxury—a kind of formal « best practice » that can, in the heat of a major deadline, be dispensed with while everyone on the team scrambles to stabilize the main tree.
La solution à ces problèmes est de toujours utiliser une branche de publication. Ce type de branche est utilisée au sein d'un logiciel de gestion de version (voir branche) pour le code destiné à être publié et peut être isolée du développement principal. L'idée d'utiliser des branches de publication n'est pas uniquement mise en œuvre par les logiciels libres, beaucoup d'équipes de développement de logiciels propriétaires font de même. Cependant, dans les environnement propriétaires, ces dernières sont parfois considérées comme un luxe, une « bonne pratique », dont l'on peut, compte tenu de contraintes de planning, se dispenser lorsque l'ensemble des équipes travaillent à la stabilisation de l'arborescence principale.
Release branches are pretty much required in Open Source projects, however. I have seen projects do releases without them, but it has always resulted in some developers sitting idle while others—usually a minority—work on getting the release out the door. The result is usually bad in several ways. First, overall development momentum is slowed. Second, the release is of poorer quality than it needed to be, because there were only a few people working on it, and they were hurrying to finish so everyone else could get back to work. Third, it divides the development team psychologically, by setting up a situation in which different types of work interfere with each other unnecessarily. The developers sitting idle would probably be happy to contribute some of their attention to a release branch, as long as that were a choice they could make according to their own schedules and interests. But without the branch, their choice becomes « Do I participate in the project today or not? » instead of « Do I work on the release today, or work on that new feature I've been developing in the mainline code?"
En revanche, les branches de publication sont assez incontournables dans le cadre d'un projet libre. J'ai vu des projets publier sans leur recours, mais le résultat y est toujours le même : une partie des développeurs n'a rien à faire, alors que les autres, en général une minorité, s'échinent à enfin sortir la version. Le résultat est en général mauvais pour plusieurs raisons. D'abord, l'effort de développement général est ralenti. Ensuite, la version publiée est de moins bonne qualité qu'elle n'aurait dû parce que seulement quelques personnes y travaillaient et qu'ils étaient pressés de terminer pour que chacun puisse se remettre à ses tâches. Enfin, cela créé une fracture psychologique entre les équipes de développement en instaurant une situation dans laquelle les différents types de travaux interfèrent entre eux. Les développeurs qui se tournent les pouces aimeraient probablement contribuer aux branches de publication, lorsqu'ils en ont le temps et l'envie. Mais sans la branche, leur choix devient « Vais-je participer au code aujourd'hui ou non ? » plutôt que « Vais-je travailler aujourd'hui sur la version en instance ou sur la nouvelle fonctionnalité que j'ai amorcée dans le code principal ? »
[modifier] Mechanics of Release Branches / Fonctionnement des branches de finalisation
The exact mechanics of creating a release branch depend on your version control system, of course, but the general concepts are the same in most systems. A branch usually sprouts from another branch or from the trunk. Traditionally, the trunk is where mainline development goes on, unfettered by release constraints. The first release branch, the one leading to the « 1.0 » release, sprouts off the trunk. In CVS, the branch command would be something like this
$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_0_X
Le processus exact de création d'une branche de publication dépend bien entendu de votre logiciel de gestion de version, mais les concepts généraux sont les mêmes pour la plupart des systèmes. Une branche est en général issue d'une autre branche ou du tronc. Généralement, le tronc désigne la partie dans laquelle se fait le développement principal, isolé des contraintes liées aux sorties. La première branche de publication, celle qui mène à la sortie de la version « 1.0 », provient du tronc. Dans CVS, la commande de branche ressemble à ceci :
$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_0_X
(All these examples assume a three-component release numbering system. While I can't show the exact commands for every version control system, I'll give examples in CVS and Subversion and hope that the corresponding commands in other systems can be deduced from those two.)
Notice that we created branch « 1.0.x » (with a literal « x ») instead of « 1.0.0 ».This is because the same minor line—i.e., the same branch—will be used for all the micro releases in that line. The actual process of stabilizing the branch for release is covered in the section called « Stabilizing a Release” later in this chapter. Here we are concerned just with the interaction between the version control system and the release process. When the release branch is stabilized and ready, it is time to tag a snapshot from the branch:
$ cd RELEASE_1_0_X-working-copy
$ cvs tag RELEASE_1_0_0
(Tous ces exemples impliquent un modèle de numérotation de version à 3 chiffres. L'espace faisant défaut ici pour fournir les commandes exactes pour chaque logiciel de gestion de version, j'utiliserai des exemples issus de CVS et Subversion en espérant que les commandes correspondantes dans les autres systèmes pourront aisément en être déduites)
Notez que nous avons créé la branche « 1.0.x » (la lettre « x ») plutôt que « 1.0.0 ».La raison est que la même ligne mineure, c'est à dire la même branche, va être employée pour toutes les micro publications dans cette ligne. Le véritable processus de stabilisation d'une branche en vue de sa sortie est discuté dans la section appelée « Stabiliser une version » plus loin dans ce chapitre. Nous nous concentrons ici uniquement sur l'interaction entre le logiciel de gestion de version et le processus de publication. Lorsque la branche est stabilisée et prête, c'est le moment d'en faire une image instantanée :
$ cd RELEASE_1_0-working-copy
$ cvs tag RELEASE_1_0_0
That tag now represents the exact state of the project's source tree in the 1.0.0 release (this is useful in case anyone ever needs to get an old version after the packaged distributions and binaries have been taken down). The next micro release in the same line is likewise prepared on the 1.0.x branch, and when it is ready, a tag is made for 1.0.1. Lather, rinse, repeat for 1.0.2, and so on. When it's time to start thinking about a 1.1.x release, make a new branch from trunk:
$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_1_X
Cette étiquette représente l'état exact de l'arborescence source du projet pour la publication de la version 1.0.0 (c'est utile au cas où quelqu'un aurait besoin de restaurer une ancienne version, après que les paquets et binaires ne soient plus disponibles). La micro publication suivante, dans la même ligne, est préparée également sur la branche 1.0.x et lorsqu'elle est prête, une étiquette est créée pour la version 1.0.1. Répéter l'opération pour la version 1.0.2 et ainsi de suite... Lorsque le moment est venu de publier une version 1.1.x, créez une nouvelle branche partant du tronc :
$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_1_X
Maintenance can continue in parallel along both 1.0.x and 1.1.x, and releases can be made independently from both lines. In fact, it is not unusual to publish near-simultaneous releases from two different lines. The older series is recommended for more conservative site administrators, who may not want to make the big jump to (say) 1.1 without careful preparation. Meanwhile, more adventurous people usually take the most recent release on the highest line, to make sure they're getting the latest features, even at the risk of greater instability.
This is not the only release branch strategy, of course. In some circumstances it may not even be the best, though it's worked out pretty well for projects I've been involved in. Use any strategy that seems to work, but remember the main points: the purpose of a release branch is to isolate release work from the fluctuations of daily development, and to give the project a physical entity around which to organize its release process. That process is described in detail in the next section.
La maintenance peut alors être poursuivie en parallèle sur les versions 1.0.x et 1.1.x et les sorties peuvent être faites indépendamment pour chaque ligne. En fait, il n'est pas inhabituel de publier de nouvelles versions presque simultanément pour deux lignes différentes. L'ancienne série est recommandée aux administrateurs plus conservateurs qui ne veulent pas sauter le pas vers la version 1.1 sans s'y être consciencieusement préparé. Mais les personnes plus aventureuses peuvent également disposer d'une version plus récente (possédant la numérotation la plus élevée), afin de profiter des fonctionnalités les plus récentes, même prix d'une plus grande instabilité.
Il ne s'agit pas de l'unique stratégie de publication de branches naturellement. Selon les circonstances elle peut ne pas être la meilleure, bien qu'elle ait fait ses preuves dans bien des projets auxquels j'ai participé. Choisissez la stratégie qui vous convient le mieux, mais souvenez vous des points essentiels : le but d'une branche de publication est d'isoler le travail à publier des fluctuations du développement journalier et de structurer le processus de publication. Ce dernier est décrit plus en détails dans la prochaine partie.
