POSS Chap 7 Part 6
Un article de Framalang Wiki.
[modifier] Maintaining Multiple Release Lines / Maintenir plusieurs versions
Most mature projects maintain multiple release lines in parallel. For example, after 1.0.0 comes out, that line should continue with micro (bugfix) releases 1.0.1, 1.0.2, etc., until the project explicitly decides to end the line. Note that merely releasing 1.1.0 is not sufficient reason to end the 1.0.x line. For example, some users make it a policy never to upgrade to the first release in a new minor or major series—they let others shake the bugs out of, say 1.1.0, and wait until 1.1.1. This isn't necessarily selfish (remember, they're forgoing the bugfixes and new features too); it's just that, for whatever reason, they've decided to be very careful with upgrades. Accordingly, if the project learns of a major bug in 1.0.3 right before it's about to release 1.1.0, it would be a bit severe to just put the bugfix in 1.1.0 and tell all the old 1.0.x users they should upgrade. Why not release both 1.1.0 and 1.0.4, so everyone can be happy?
Les projets les plus matures maintiennent plusieurs versions en parallèle. Par exemple, la version 1.0.0 une fois publiée peut continuer à vivre au travers de micro versions (correctifs) 1.0.1, 1.0.2, etc. jusqu'à ce que le projet décide explicitement de mettre un terme à son support. Le simple fait de publier la version 1.1.0 n'est pas une raison suffisante pour clore la série des versions 1.0.x. Certains utilisateurs se fixent comme règle de ne jamais utiliser une première version mineure ou majeure et laissent le soin aux autres de lever les bogues de la version 1.1.0 et attendent la version 1.1.1. Il ne faut pas nécessairement considérer ceci comme de l'égoïsme (souvenez-vous qu'ils renoncent ainsi aux correctifs et aux nouvelles fonctionnalités) : ils ont simplement décidé de ne prendre aucun risque avec les mises à jour à cause de contraintes spécifiques. De la même manière, si le projet découvre un bogue important dans la version 1.0.3, peu de temps avant de sortir la version 1.1.0, ilserait sévère de ne corriger ce bogue que dans la version 1.1.0 et de demander à tous les utilisateurs des versions 1.0.x de se mettre à jour. Pourquoi ne pas publier à la fois les versions 1.1.0 et 1.0.4 pour contenter tout le monde ?
After the 1.1.x line is well under way, you can declare 1.0.x to be at end of life. This should be announced officially. The announcement could stand alone, or it could be mentioned as part of a 1.1.x release announcement; however you do it, users need to know that the old line is being phased out, so they can make upgrade decisions accordingly.
Une fois la ligne de version 1.1.x bien avancée, vous pouvez déclarer la fin de support des versions 1.0.x, ceci officiellement. Cette annonce peut être faite seule ou mentionnée lors de la sortie de la 1.1.x. Peu importe la manière mais les utilisateurs doivent être informés que l'ancienne ligne n'est plus supportée pour être en mesure de prendre des décisions sur une éventuelle montée de version.
Some projects set a window of time during which they pledge to support the previous release line. In an Open Source context, "support" means accepting bug reports against that line, and making maintenance releases when significant bugs are found. Other projects don't give a definite amount of time, but watch incoming bug reports to gauge how many people are still using the older line. When the percentage drops below a certain point, they declare end of life for the line and stop supporting it.
Certains projets fixent une durée de support des versions précédentes. Dans un contexte Open Source, « supporter » signifie accepter les rapports de bogues et publier des versions de maintenance lorsque des bogues importants sont trouvés. D'autres projets ne fournissent pas de durées précises mais s'appuient sur le nombre de rapports de bogue reçus pour évaluer le nombre d'utilisateurs de l'ancienne ligne de version. Lorsque la proportion descend sous un certain pourcentage, ils déclarent la fin de cette ligne et en stoppent le support.
For each release, make sure to have a target version or target milestone available in the bug tracker, so people filing bugs will be able to do so against the proper release. Don't forget to also have a target called "development" or "latest" for the most recent development sources, since some people—not only active developers—will often stay ahead of the official releases.
A chaque publication, assurez vous que le système de suivi de bogues propose bien les versions et jalons nécessaires pour permettre aux personnes les rapportant de les associer à la version adéquate. N'oubliez pas non plus de proposer un jalon « Développement » ou « Récent » pour la version de développement puisque certaines personnes -et pas uniquement des développeurs actifs- gardent souvent d'une longueur d'avance sur la version officielle.
[modifier] Security Releases / Mises à jour de sécurité
Most of the details of handling security bugs were covered in the section called « Announcing Security Vulnerabilities » in Chapter 6, Communications, but there are some special details to discuss for doing security releases.
La plupart des détails concernant la gestion des failles de sécurité ont été abordés dans la section « Communiquer à propos des failles de sécurité » du Chapitre 6, « Communication », mais il nous reste à préciser certains points sur la publication des mises à jour de sécurité.
A security release is a release made solely to close a security vulnerability. The code that fixes the bug cannot be made public until the release is available, which means not only that the fixes cannot be committed to the repository until the day of the release, but also that the release cannot be publicly tested before it goes out the door. Obviously, the developers can examine the fix among themselves, and test the release privately, but widespread real-world testing is not possible.
Une mise à jour de sécurité est une version dédiée à la résolution d'une vulnérabilité. Le code qui résout le problème ne doit pas être rendu public avant que la mise à jour ne soit disponible, ce qui signifie non seulement que le correctif ne peut pas être enregistré dans le dépôt avant le jour de sa sortie mais également que cette version ne peut pas être testée publiquement avant d'être officiellement publiée. Bien entendu, les développeurs peuvent examiner le correctif en interne et tester la version en privé, mais un test à grande échelle n'est pas possible.
Because of this lack of testing, a security release should always consist of some existing release plus the fixes for the security bug, with no other changes. This is because the more changes you ship without testing, the more likely that one of them will cause a new bug, perhaps even a new security bug! This conservatism is also friendly to administrators who may need to deploy the security fix, but whose upgrade policy prefers that they not deploy any other changes at the same time.
En raison de ce manque de tests, une mise à jour de sécurité doit être constituée uniquement d'une version existante à laquelle on ajoute les correctifs de sécurité, ceci sans aucune autre modification. La raison est simple : plus vous ajoutez de modifications non testées plus vous augmentez le risque que l'une d'entre elles contienne un nouveau bogue, peut-être même un nouveau bogue de sécurité ! Ce conservatisme va aussi dans le sens des administrateurs qui pourraient avoir besoin de déployer le correctif de sécurité sans embarquer d'autres changements.
Making a security release sometimes involves some minor deception. For example, the project may have been working on a 1.1.3 release, with certain bug fixes to 1.1.2 already publicly declared, when a security report comes in. Naturally, the developers cannot talk about the security problem until they make the fix available; until then, they must continue to talk publicly as though 1.1.3 will be what it's always been planned to be. But when 1.1.3 actually comes out, it will differ from 1.1.2 only in the security fixes, and all those other fixes will have been deferred to 1.1.4 (which, of course, will now also contain the security fix, as will all other future releases).
Les mises à jour de sécurité impliquent parfois quelques légères duperies. Par exemple, le projet pourrait déjà travailler sur la sortie de la 1.1.3 -déjà été publiquement annoncée- corrigeant quelques bogues de la version 1.1.2 lorsqu'un rapport de sécurité survient. Évidemment, les développeurs ne peuvent pas parler du problème de sécurité jusqu'à ce qu'ils aient rendu disponible un correctif. Ils doivent continuer à parler en public de la version 1.1.3 avec son contenu prévu initialement. Mais la version 1.1.3 réelle n'embarquera finalement que le correctif de sécurité et tous les autres changements devront être reportés à la 1.1.4 (qui contiendra bien sûr le correctif de sécurité, ainsi que toutes les versions ultérieures).
You could add an extra component to an existing release to indicate that it contains security changes only. For example, people would be able to tell just from the numbers that 1.1.2.1 is a security release against 1.1.2, and they would know that any release "higher" than that (e.g., 1.1.3, 1.2.0, etc.) contains the same security fixes. For those in the know, this system conveys a lot of information. On the other hand, for those not following the project closely, it can be a bit confusing to see a three-component release number most of the time with an occasional four-component one thrown in seemingly at random. Most projects I've looked at choose consistency and simply use the next regularly scheduled number for security releases, even when it means shifting other planned releases by one.
Vous pouvez ajouter une numéro supplémentaire à une version existante pour indiquer qu'elle contient uniquement des changements relatifs à la sécurité. Par exemple, il pourraient possible de déduire du numéro de version « 1.1.2.1 » qu'il s'agit d'une mise à jour de sécurité de la version « 1.1.2 » et que toute version supérieure (1.1.3, 1.2.0, etc.) contient le même correctif de sécurité. Pour les utilisateurs avertis, ce système fournit de nombreuses informations. Néanmoins, cela peut sembler étrange à ceux qui ne suivent pas le projet de près d'utiliser un numéro à trois chiffres la majeure partie du temps puis un quatrième de temps en temps. La plupart des projets que j'ai suivis choisissent la constance et utilisent simplement le numéro suivant pour les mises à jour de sécurité, même si cela implique de repousser d'un numéro les versions prévues.
