POSS Chap 7 Part 1

Un article de Framalang Wiki.

Jump to: navigation, search


Sommaire

[modifier] Release Numbering / Numérotation des versions

Before we talk about how to make a release, let's look at how to name releases, which requires knowing what releases actually mean to users. A release means that:

  • Old bugs have been fixed. This is probably the one thing users can count on being true of every release.
  • New bugs have been added. This too can usually be counted on, except sometimes in the case of security releases or other one-offs (see the section called “Security Releases” later in this chapter).
  • New features may have been added.
  • New configuration options may have been added, or the meanings of old options may have changed subtly. The installation procedures may have changed slightly since the last release too, though one always hopes not.
  • Incompatible changes may have been introduced, such that the data formats used by older versions of the software are no longer useable without undergoing some sort of (possibly manual) one-way conversion step.


Avant d'aborder la conception d'une version parlons d'abord de comment nommer les versions, ce qui implique la connaissance de la signification des sorties pour les utilisateurs. Une sortie signifie que :

  • Les anciens bogues ont été réparés. C'est probablement la chose qu'ils attendent à chaque sortie
  • De nouveaux bogues ont été ajoutés. Ils s'y attendent aussi, à part en ce qui concerne les correctifs de sécurité et autres cas exceptionnels (voir la section appelée « Correctifs de sécurité » plus loin dans ce chapitre)
  • De nouvelles fonctionnalités peuvent avoir été ajoutées
  • De nouvelles options de configuration peuvent avoir été ajoutées ou la signification d'anciennes options peut avoir légèrement changé. Les procédures d'installation peuvent avoir été légèrement modifiées depuis la version précédente également, bien qu'en général personne ne le souhaite
  • Des changements apportés peuvent rendre certaines données incompatibles et le format de données utilisé dans d'anciennes versions du logiciel ne sont plus utilisables sans passer par une étape de conversion unidirectionnelle (potentiellement manuelle)

As you can see, not all of these are good things. This is why experienced users approach new releases with some trepidation, especially when the software is mature and was already mostly doing what they wanted (or thought they wanted). Even the arrival of new features is a mixed blessing, in that it may mean the software will now behave in unexpected ways.

The purpose of release numbering, therefore, is twofold: obviously the numbers should unambiguously communicate the ordering of releases (i.e., by looking at any two releases' numbers, one can know which came later), but also they should indicate as compactly as possible the degree and nature of the changes in the release.

Comme vous pouvez le voir, ce ne sont pas que de bonnes choses. C'est la raison pour laquelle les utilisateurs expérimentés appréhendent toujours un peu les sorties, surtout quand le logiciel est mature et réalise déjà presque tout ce qu'ils veulent faire avec (ou du moins, pensent qu'ils veulent faire avec). Même l'arrivée de nouvelles fonctionnalités a ses avantages et ses inconvénients puisque le comportement du logiciel peut être modifié.

La numérotation a donc deux buts : de toute évidence le numéro devrait faire transparaître sans ambiguïté l'ordre de sortie (c'est-à-dire qu'en regardant deux numéros de version on devrait savoir quelle est la plus récente), mais elle devrait également indiquer de manière aussi condensée que possible le degré et la nature des changements de cette version.
All that in a number? Well, more or less, yes. Release numbering strategies are one of the oldest bikeshed discussions around (see the section called “The Softer the Topic, the Longer the Debate” in Chapter 6, Communications), and the world is unlikely to settle on a single, complete standard anytime soon. However, a few good strategies have emerged, along with one universally agreed-on principle: be consistent. Pick a numbering scheme, document it, and stick with it. Your users will thank you.
Tout cela dans un numéro ? Et bien, plus ou moins, oui. La stratégie de numérotation des sorties est l'une des plus vieilles controverse (voir la section appelée « Plus le sujet est facile, plus long est le débat » dans le Chapitre 6, Communication) et je ne vois pas arriver un standard complet et unique d'ici peu. Cependant, quelques bonnes stratégies se sont démarquées est un principe est accepté par tous : soyez cohérents. Choisissez une stratégie de numérotation, décrivez la et restez-y fidèle. Vos utilisateurs vous en seront reconnaissants.

[modifier] Release Number Components / Les éléments de la numérotation

This section describes the formal conventions of release numbering in detail, and assumes very little prior knowledge. It is intended mainly as a reference. If you're already familiar with these conventions, you can skip this section.
Cette partie décrit en détail les conventions formelles de la numérotation de version et ne nécessite que peu de connaissances préalables. Vous devez la voir comme une référence. Si vous êtes déjà familier avec ces conventions vous pouvez vous rendre directement à la section suivante.

Release numbers are groups of digits separated by dots:

Scanley 2.3 Singer 5.11.4

...and so on. The dots are not decimal points, they are merely separators; « 5.3.9 » would be followed by « 5.3.10 ».A few projects have occasionally hinted otherwise, most famously the Linux kernel with its « 0.95 », « 0.96"... « 0.99 » sequence leading up to Linux 1.0, but the convention that the dots are not decimals is now firmly established and should be considered a standard. There is no limit to the number of components (digit portions containing no dots), but most projects do not go beyond three or four. The reasons why will become clear later.

Les numéros de versions sont des groupes de chiffres séparés par des points :

Scanley 2.3 Singer 5.11.4

... et ainsi de suite. Les points ne sont pas des virgules pour séparer les décimales, ce sont simplement des séparateurs; « 5.3.9 » sera suivi par « 5.3.10 ».Certains projets ont parfois dévié de cette voie, l'exemple le plus connu est le noyau Linux avec sa suite « 0.95 », « 0.96 », « 0.99 » pour arriver à Linux 1.0, mais la convention selon laquelle les points ne séparent pas les décimales est maintenant bien établie et devrait être considérée comme une norme. Il n'y a aucune limite au nombre de composantes (portions de chiffres ne contenant pas de points), mais la plupart des projets ne dépassent pas trois ou quatre. Les raisons vous apparaîtront plus clairement par la suite.

In addition to the numeric components, projects sometimes tack on a descriptive label such as « Alpha » or « Beta » (see Alpha and Beta), for example:

Scanley 2.3.0 (Alpha) Singer 5.11.4 (Beta)

An Alpha or Beta qualifier means that this release precedes a future release that will have the same number without the qualifier. Thus, « 2.3.0 (Alpha) » leads eventually to « 2.3.0 ».In order to allow several such candidate releases in a row, the qualifiers themselves can have meta-qualifiers. For example, here is a series of releases in the order that they would be made available to the public:

Scanley 2.3.0 (Alpha 1) Scanley 2.3.0 (Alpha 2) Scanley 2.3.0 (Beta 1) Scanley 2.3.0 (Beta 2) Scanley 2.3.0 (Beta 3)

Scanley 2.3.0

En plus de la composante chiffrée, les projets ajoutent encore un étiquette telle que « Alpha » ou « Beta » (voir « Alpha et Beta »), par exemple :

Scanley 2.3.0 (Alpha) Singer 5.11.4 (Beta)

Une étiquette Alpha ou Beta signifie que cette sortie précède une sortie prochaine avec le même numéro, mais sans l'étiquette. Ainsi, « 2.3.0 (Alpha) » aboutira finalement à « 2.3.0 ».Afin de laisser de la place pour plusieurs pré-sorties de suite, les étiquettes elles-mêmes peuvent porter une meta-étiquette. Par exemple voici une série de sorties dans l'ordre dans lequel elles seraient mises à disposition du public :

Scanley 2.3.0 (Alpha 1) Scanley 2.3.0 (Alpha 2) Scanley 2.3.0 (Beta 1) Scanley 2.3.0 (Beta 2) Scanley 2.3.0 (Beta 3)

Scanley 2.3.0

Notice that when it has the « Alpha » qualifier, Scanley « 2.3 » is written as « 2.3.0 ».The two numbers are equivalent—trailing all-zero components can always be dropped for brevity—but when a qualifier is present, brevity is out the window anyway, so one might as well go for completeness instead.

Other qualifiers in semi-regular use include « Stable », « Unstable », « Development », and « RC » (for « Release Candidate »). The most widely used ones are still « Alpha » and « Beta », with « RC » running a close third place, but note that « RC » always includes a numeric meta-qualifier. That is, you don't release « Scanley 2.3.0 (RC) », you release « Scanley 2.3.0 (RC 1) », followed by RC2, etc.

Vous remarquerez que quand il possède le qualificatif « Alpha », Scanley « 2.3 » est écrit comme « 2.3.0 ».Les deux nombres sont équivalents, les 0 en fin de numérotation peuvent toujours être abandonnés par soucis de concision, mais lorsqu'un qualificatif est présent, on ne peut de toute façon pas faire court et on pourra plutôt utiliser le nom complet.

D'autres qualificatifs utilisés relativement souvent sont « Stable », « Unstable », « Development » et « RC » (pour « Release Candidate »). Les plus utilisés restent « Alpha » et « Beta », « RC » n'est pas loin derrière à la troisième place, mais vous remarquerez que « RC » est toujours suivi d'un meta-qualificatif numérique. C'est-à-dire que vous ne publiez pas « Scanley 2.3.0 (RC) », vous publiez « Scanley 2.3.0 (RC 1) », suivi par RC2, etc.

Those three labels, « Alpha », « Beta », and « RC », are pretty widely known now, and I don't recommend using any of the others, even though the others might at first glance seem like better choices because they are normal words, not jargon. But people who install software from releases are already familiar with the big three, and there's no reason to do things gratuitously differently from the way everyone else does them.

Although the dots in release numbers are not decimal points, they do indicate place-value significance. All « 0.X.Y » releases precede « 1.0 » (which is equivalent to « 1.0.0 », of course). « 3.14.158 » immediately precedes « 3.14.159 », and non-immediately precedes « 3.14.160 » as well as « 3.15.anything », and so.

Ces trois étiquettes, « Alpha », « Beta » et « RC » sont largement connues maintenant et je ne recommanderai pas l'usage des autres même si a priori se sont de meilleurs choix car ce sont des mots compréhensibles, pas du jargon. Mais les gens qui installent des logiciels non-finalisés sont déjà familiers avec ce triptyque et il n'y a aucune raison de réinventer la roue.

Même si les points dans les numéros de version ne sont pas des virgules, ils indiquent quand même un certain ordre. Toutes les versions « 0.X.Y » précèdent la « 1.0 » (qui est équivalente à la « 1.0.0 », bien sûr). La « 3.14.158 » précède immédiatement la « 3.14.159 » et ne précède pas directement la « 3.14.160 » ou encore la « 3.15.0 » et ainsi de suite.
A consistent release numbering policy enables a user to look at two release numbers for the same piece of software and tell, just from the numbers, the important differences between those two releases. In a typical three-component system, the first component is the major number, the second is the minor number, and the third is the micro number. For example, release « 2.10.17 » is the seventeenth micro release in the tenth minor release line within the second major release series. The words « line » and « series » are used informally here, but they mean what one would expect. A major series is simply all the releases that share the same major number, and a minor series (or minor line) consists of all the releases that share the same minor and major number. That is, « 2.4.0 » and « 3.4.1 » are not in the same minor series, even though they both have « 4 » for their minor number; on the other hand, « 2.4.0 » and « 2.4.2 » are in the same minor line, though they are not adjacent if « 2.4.1 » was released between them.
Une politique de numérotation de versions cohérente permet aux utilisateurs de distinguer en regardant deux numéros de version d'un même logiciel, uniquement d'après les chiffres, les différences importantes qui existent entre ces deux versions. Dans le cas classique d'une numérotation à trois composantes, le premier est le nombre principale, le deuxième est le nombre mineur et le troisième est le micro-nombre. Par exemple, la version « 2.10.17 » est la dix-septième micro sortie de la dixième sortie mineure au sein de la deuxième version principale. Les mots « lignes » et « séries » sont utilisés de manière informelle ici, mais ils veulent dire ce qu'ils veulent dire. Une série majeur comprend toutes les sorties qui partagent le même nombre principal et une série mineure (une ligne mineure) contient toutes les versions qui partagent le même nombre mineur et le même nombre principal. Par exemple, la « 2.4.0 » et la « 3.4.1 » ne sont pas dans la même série mineure, même si elles ont toutes les deux le « 4 » comme chiffre mineur, à l'opposé, la « 2.4.0 » et la « 2.4.2 » sont dans la même ligne mineure bien qu'elles ne soient pas adjacentes si la « 2.4.1 » a été publiée entre les deux.

The meanings of these numbers are exactly what you'd expect: an increment of the major number indicates that major changes happened; an increment of the minor number indicates minor changes; and an increment of the micro number indicates really trivial changes. Some projects add a fourth component, usually called the patch number, for especially fine-grained control over the differences between their releases (confusingly, other projects use « patch » as a synonym for « micro » in a three-component system). There are also projects that use the last component as a build number, incremented every time the software is built and representing no change other than that build. This helps the project link every bug report with a specific build, and is probably most useful when binary packages are the default method of distribution.

Although there are many different conventions for how many components to use, and what the components mean, the differences tend to be minor—you get a little leeway, but not a lot. The next two sections discuss some of the most widely used conventions.

La signification de ces nombres est exactement ce à quoi vous vous attendez : une incrémentation du nombre principal indique que de grands changements se sont produits, une incrémentation du nombre mineur indique des modifications mineures et une incrémentation du micro-nombre indique des changements vraiment triviaux. Certains projets ajoutent une quatrième composante, appelée habituellement le numéro du correctif, pour un contrôle particulièrement fin des différences entre les versions (d'autres projets utilisent « correctif » comme synonyme de « micro » dans un système à trois composantes, ce qui peut prêter à confusion). Il y a aussi d'autres projets qui utilisent la dernière composante comme un numéro de « build ».Cela permet au projet de relier tous les rapports de bogue à un « build » particulier et cette méthode se révèle sûrement être la mieux adaptée lorsque le logiciel est distribué sous la forme de paquets binaires.

Bien que de nombreuses conventions différentes concernant le nombre composantes que vous devriez utiliser et leur signification existent, les différences restent minimes, vous avez une certaine marge, mais pas tant que ça. Les deux prochaines parties portent sur les conventions les plus utilisées.

[modifier] The Simple Strategy / La stratégie simple

Most projects have rules about what kinds of changes are allowed into a release if one is only incrementing the micro number, different rules for the minor number, and still different ones for the major number. There is no set standard for these rules yet, but here I will describe a policy that has been used successfully by multiple projects. You may want to just adopt this policy in your own project, but even if you don't, it's still a good example of the kind of information release numbers should convey. This policy is adapted from the numbering system used by the APR project, see http://apr.apache.org/versioning.html.
La plupart des projets ont des règles qui régissent le type de modifications autorisées dans une version si l'on incrémente seulement le micro-nombre, d'autres règles pour le nombre mineur et d'autres encore pour le nombre principal. Il n'y a pas de standard établi pour ces règles encore mais je vais décrire ici une règle qui a été employée avec succès par plusieurs projets. Vous pouvez très bien adopter ces règles dans votre propre projet, mais même si vous ne le faites pas cela reste un bon exemple du type d'information que doit véhiculer le numéro de version. Ces règles sont tirées du système de numérotation utilisé par le projet APR, voir http://apr.apache.org/versioning.html.
  1. Changes to the micro number only (that is, changes within the same minor line) must be both forward- and backward-compatible. That is, the changes should be bug fixes only, or very small enhancements to existing features. New features should not be introduced in a micro release.
  
  2. Changes to the minor number (that is, within the same major line) must be backward-compatible, but not necessarily forward-compatible. It's normal to introduce new features in a minor release, but usually not too many new features at once.
  
  3. Changes to the major number mark compatibility boundaries. A new major release can be forward- and backward-incompatible. A major release is expected to have new features, and may even have entire new feature sets.

1. Les modifications du micro-nombre seul (c'est-à-dire, les modifications au sein de la même ligne mineure) doivent être compatibles à la fois avec les versions suivantes et les versions précédentes. Ce qui veut dire que les modifications ne devraient être que des correctifs de bogue ou de petites améliorations de fonctionnalités déjà existantes. De nouvelles fonctionnalités ne devraient pas être introduites dans une micro sortie.
  
2. Les modifications du nombre mineur (c'est-à-dire, dans la même ligne principale) doivent être retro-compatibles, mais pas nécessairement avec les versions futures. Il est normal d'introduire de nouvelles fonctionnalités dans une sortie mineur, mais généralement pas trop à la fois.

3. Des modifications du nombre majeur marquent des limites de compatibilité. Une nouvelle sortie majeure peut être compatible avec les versions suivantes et précédentes. Une sortie majeure est censée posséder de nouvelles fonctionnalités et peut même avoir tout un nouvel ensemble de fonctionnalités.
What backward-compatible and forward-compatible mean, exactly, depends on what your software does, but in context they are usually not open to much interpretation. For example, if your project is a client/server application, then « backward-compatible » means that upgrading the server to 2.6.0 should not cause any existing 2.5.4 clients to lose functionality or behave differently than they did before (except for bugs that were fixed, of course). On the other hand, upgrading one of those clients to 2.6.0, along with the server, might make new functionality available for that client, functionality that 2.5.4 clients don't know how to take advantage of. If that happens, then the upgrade is not « forward-compatible": clearly you can't now downgrade that client back to 2.5.4 and keep all the functionality it had at 2.6.0, since some of that functionality was new in 2.6.0.
La signification exacte de la compatibilité avec les versions précédentes et suivantes dépend de ce que le logiciel fait mais prise dans un contexte la signification est relativement claire. Par exemple, si votre projet est une application client/serveur, alors « retro-compatible » signifie que mettre à jour le serveur avec la version 2.6.0 ne devrait pas empêcher les clients utilisant la version 2.5.4 de fonctionner comme avant (hormis pour les bogues corrigés évidemment). D'un autre côté, mettre à jour l'un de ces clients avec la version 2.6.0, en même temps que le serveur, peut apporter de nouvelles fonctionnalités au client, des fonctionnalités que les clients avec la version 2.5.4 ne peuvent pas utiliser. Si cela se produit, alors la mise à jour n'est pas compatible : vous ne pouvez évidemment pas revenir en arrière et remettre la version 2.5.4 sur le poste client en gardant les fonctionnalités obtenue avec la 2.6.0 puisque certaines de ces fonctionnalités sont apportées par la version 2.6.0
This is why micro releases are essentially for bug fixes only. They must remain compatible in both directions: if you upgrade from 2.5.3 to 2.5.4, then change your mind and downgrade back to 2.5.3, no functionality should be lost. Of course, the bugs fixed in 2.5.4 would reappear after the downgrade, but you wouldn't lose any features, except insofar as the restored bugs prevent the use of some existing features.
C'est pourquoi les micro sorties ne font quasiment que corriger des bogues. Elles doivent être compatibles dans les deux sens : si vous faites une mise à jour de la version 2.5.3 vers la version 2.5.4 et qu'ensuite vous changez d'avis pour revenir à la version 2.5.3 vous ne devriez pas perdre de fonctionnalités. Évidemment, les bogues corrigés dans la version 2.5.4 ré-apparaîtront après le retour en arrière, mais vous ne devez pas perdre de fonctionnalité, sauf si peut-être un bogue corrigé par la nouvelle version empêche l'exécution de fonctionnalités existantes.
Client/server protocols are just one of many possible compatibility domains. Another is data formats: does the software write data to permanent storage? If so, the formats it reads and writes need to follow the compatibility guidelines promised by the release number policy. Version 2.6.0 needs to be able to read the files written by 2.5.4, but may silently upgrade the format to something that 2.5.4 cannot read, because the ability to downgrade is not required across a minor number boundary. If your project distributes code libraries for other programs to use, then APIs are a compatibility domain too: you must make sure that source and binary compatibility rules are spelled out in such a way that the informed user need never wonder whether or not it's safe to upgrade in place. She will be able to look at the numbers and know instantly.
Les protocoles client/serveur ne représentent qu'un domaine de compatibilité parmi tant d'autres. On peut également citer le format des données : est-ce que le logiciel écrit des données sur une unité de stockage permanent ? Si c'est le cas, les formats employés pour lire et écrire doivent suivre les indications promises par les règles de numérotation. La version 2.6.0 doit pouvoir lire les fichiers écrits avec la version 2.5.4, mais peu très bien mettre à jour discrètement le format avec pour conséquence sa non-interopérabilité avec la version 2.5.4, parce que la compatibilité des versions antérieures n'est pas requise quand on change de numéro mineur. Si votre projet distribue des librairies de code que d'autres programmes emploient, alors les API sont aussi un autre domaine de compatibilité : vous devez vous assurer que les règles de compatibilité de la source et des binaires sont bien énoncées de manière à ce que les utilisateurs informés n'aient pas à se demander s'ils peuvent mettre à jour leur version sans risque. Ils pourront regarder la numérotation et sauront instantanément.
In this system, you don't get a chance for a fresh start until you increment the major number. This can often be a real inconvenience: there may be features you wish to add, or protocols that you wish to redesign, that simply cannot be done while maintaining compatibility. There's no magic solution to this, except to try to design things in an extensible way in the first place (a topic easily worth its own book, and certainly outside the scope of this one). But publishing a release compatibility policy, and adhering to it, is an inescapable part of distributing software. One nasty surprise can alienate a lot of users. The policy just described is good partly because it's already quite widespread, but also because it's easy to explain and to remember, even for those not already familiar with it.
Ce système vous empêche de changer les choses profondément tant que vous n'incrémentez pas le nombre majeur. Cela peut souvent devenir un vrai handicap : vous avez peut-être envie d'ajouter des fonctionnalités ou de re-penser certains protocoles mais vous ne pourrez pas le faire par soucis de compatibilité. Il n'existe pas de solution magique, à part peut-être si dès le départ vous décidez de tout construire de façon extensible (il faudrait un livre entier pour couvrir ce sujet et c'est bien au delà des buts de cet ouvrage). Mais vous devez publier des règles de compatibilité et vous y tenir, c'est une chose à laquelle vous ne pouvez échapper dans la distribution d'un logiciel. Une mauvaise surprise pourrait vous mettre de nombreux utilisateurs à dos. Les règles décrites précédemment sont bonnes en partie parce qu'elles sont répandues, mais aussi parce qu'elles sont simples à expliquer et à mémoriser, même pour ceux qui n'y sont pas familiers.
It is generally understood that these rules do not apply to pre-1.0 releases (although your release policy should probably state so explicitly, just to be clear). A project that is still in initial development can release 0.1, 0.2, 0.3, and so on in sequence, until it's ready for 1.0, and the differences between those releases can be arbitrarily large. Micro numbers in pre-1.0 releases are optional. Depending on the nature of your project and the differences between the releases, you might find it useful to have 0.1.0, 0.1.1, etc., or you might not. Conventions for pre-1.0 release numbers are fairly loose, mainly because people understand that strong compatibility constraints would hamper early development too much, and because early adopters tend to be forgiving anyway.
De manière générale, ces règles ne s'appliquent pas aux versions avant la 1.0 (bien que vos règles puissent l'établir explicitement, juste pour être clair). Un projet qui en est toujours à un stade de développement initial peut sortir les versions 0.1, 0.2, 0.3 et ainsi de suite l'une après l'autre jusqu'à ce qu'il soit prêt pour la version 1.0 et les différences entre ces versions peuvent être arbitrairement importante. Les micro-nombres pour les sorties avant la 1.0 sont optionnels. Selon la nature de votre projet et les différences entre les sorties, vous trouverez peut-être utile ou non d'avoir des versions 0.1.0, 0.1.1, etc. Les conventions pour les sorties précédents la version 1.0 ne sont pas très strictes, principalement parce que les gens comprennent qu'avoir de fortes contraintes de compatibilité entraverait trop le développement initial et parce que les premiers utilisateurs pardonnent facilement de toute manière.
Remember that all these injunctions only apply to this particular three-component system. Your project could easily come up with a different three-component system, or even decide it doesn't need such fine granularity and use a two-component system instead. The important thing is to decide early, publish exactly what the components mean, and stick to it.
Souvenez vous que toutes ces injonctions ne s'appliquent qu'à ce système à trois composantes particulier. Votre projet pourrait facilement élaborer un système à trois composantes différent ou même décider que vous n'avez pas besoin d'une telle finesse et adopter un système à deux composantes plutôt. La chose importante est de décider tôt, publier exactement ce que signifient les composantes et vous y tenir.

[modifier] The Even/Odd Strategy / La stratégie pair/impair

Some projects use the parity of the minor number component to indicate the stability of the software: even means stable, odd means unstable. This applies only to the minor number, not the major and micro numbers. Increments in the micro number still indicate bug fixes (no new features), and increments in the major number still indicate big changes, new feature sets, etc.
Certains projets se servent de la parité du nombre mineur pour indiquer la stabilité du logiciel : pair signifie stable, impair signifie instable. Ceci ne s'applique qu'au nombre mineur, pas au nombre principal ou aux micro-nombres. L'incrémentation du micro-nombre indique toujours des corrections de bogues (pas de nouvelles fonctionnalités) et l'incrémentation du nombre principal indique toujours de grands changements, un ensemble de nouvelles fonctionnalités, etc.
The advantage of the even/odd system, which has been used by the Linux kernel project among others, is that it offers a way to release new functionality for testing without subjecting production users to potentially unstable code. People can see from the numbers that « 2.4.21 » is okay to install on their live Web server, but that « 2.5.1 » should probably stay confined to home workstation experiments. The development team handles the bug reports that come in from the unstable (odd-minor-numbered) series, and when things start to settle down after some number of micro releases in that series, they increment the minor number (thus making it even), reset the micro number back to « 0 », and release a presumably stable package.
L'avantage du système pair/impair, qui est employé par le projet du noyau de Linux entre autres, est qu'il offre un moyen de sortir de nouvelles fonctionnalités pour qu'elles soient testées sans soumettre les utilisateurs à un code potentiellement instable. Les gens peuvent comprendre grâce aux chiffres que la version « 2.4.21 » est suffisamment stable pour être installée sur leur serveur Web, mais que la version « 2.5.1 » devrait rester confinée aux expérimentations faites sur la station de travail de la maison. L'équipe de développement traite les rapports de bogue qui arrivent pour la série instable (dont le nombre mineur est impaire) et quand les choses commencent à se calmer après quelques micro sorties dans cette série ils incrémentent d'une unité le nombre mineur, le rendant donc pair, ils remettent le micro-nombre à « 0 » et sortent un paquet présumé stable.
This system preserves, or at least, does not conflict with, the compatibility guidelines given earlier. It simply overloads the minor number with some extra information. This forces the minor number to be incremented about twice as often as would otherwise be necessary, but there's no great harm in that. The even/odd system is probably best for projects that have very long release cycles, and which by their nature have a high proportion of conservative users who value stability above new features. It is not the only way to get new functionality tested in the wild, however. the section called “Stabilizing a Release” later in this chapter describes another, perhaps more common, method of releasing potentially unstable code to the public, marked so that people have an idea of the risk/benefit trade-offs immediately on seeing the release's name.
Ce système préserve, ou au moins n'entre pas en conflit avec, les indications de compatibilité données précédemment. Il ne fait qu'attribuer des informations supplémentaires au nombre mineur. Le nombre mineur se retrouve incrémenter au moins deux fois plus souvent qu'il ne serait nécessaire autrement, mais il n'y a rien de grave là dedans. Le système pair/impair est sans doute mieux adapté pour le projets qui ont des longs cycles de développement et qui, par nature, ont une grande proportion d'utilisateurs conservateurs qui préfèrent la stabilité par rapport à de nouvelles fonctionnalités. Ce n’est pas l’unique moyen pour que ces nouvelles fonctionnalités soient testées en « situation réelle » cependant. La partie nommée « Stabiliser une version » plus loin dans ce chapitre en décrit une autre, peut-être plus commune, pour proposer du code potentiellement instable au public, avec un avertissement dans le nom afin que les gens puissent évaluer le rapport risque/bénéfice simplement en voyant le nom de la version.
Récupérée de « http://www.framalang.org/wiki/POSS_Chap_7_Part_1 »