Version x.x.x : la sémantique des versions

Version 3.0, version 3.1.125, version bêta, RC, GM, etc. Il est toujours utile de revenir aux fondamentaux de la sémantique des versions. Prenons un exemple : version 1.1.201.x.x -> numérotion de la version majeurex.1.x -> numérotation mineurex.x.20 -> patch, bug fixDans cet exemple, nous avons 3 éléments. La version majeure change quand les changement sont importants. Dans ce cas, on justifie le changement de numéro. Dans le cas de Python, nous avons la release 2 et la release 3. Le second numéro concerne le plus souvent les mises à jour dites mineures. Ce sont souvent des ajustements, des fonctionnalités qui ne sont pas considérés comme majeures. Le dernier numéro est souvent utilisé pour les mises à jour de sécurité, des corrections de bugs, etc. Généralement, il n'y a pas de nouvelles fonctionnalités.Il existe parfois d'autres sous-versions.Au-delà, on parle d'alpha, preview, bêta, RC, release, GA, build. Cela indique un état non final de la version. Prenons un exemple : OpenJDK 25 build 19.OpenJDK : nom du langage, du logiciel, etc.25 : version majeurebuild 19 : indique une pré-version en développement et c'est la 19e version buildée et distribuée.Il est même possible d'ajouter à la numéroté un état du développement  : preview, b pour bêta ou rc pour release candidate.Pour certains projets, on parlera de canaux (channels) de versions. Chromium utilise sur les versions desktop 4 canaux différents. Chaque canal correspond à un état de développement :- canary : pré-version buildée chaque nuit, réservée aux développeurs expérimentés- dev : version plus avancée et plus stable- beta : version plus table et complète pour tests élargis mais pas pour la production- stable : branche de la version finale et stabilisée pour tous les utilisateursRevenons à nos alpha, bêta, RC, release / GA / GM. Les alpha, bêta ou preview sont les versions en développement pour une audience plus ou moins élargie. La RC (release candidate) est une version pré-finale : les fonctionnalités sont complètes et il s'agit de trouver et fixer les derniers bugs. Plusieurs RC peuvent être distribuées. L'ultime étape est la version finale qui peut prendre différent nom selon le logiciel ou le projet : release, GA, GM, stable. Sur Azure, on parlera de GA (disponibilité générale) et non de release finale ou de version 1.0. Attention : l’identifiant de version majeure zéro (0.y.z) est destiné au développement initial. Tout ou partie peut être modifié à tout moment. L’API publique ne devrait pas être considérée comme stable. (règle 4 du semver)En reprenant la définition du semver.org :Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles.Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format MAJEURE.MINEURE.CORRECTIF.Catégorie actualité: TechnologiesVersion, versioningImage actualité AMP: 

Articles similaires

Commentaires

Nom

E-mail

Commentaire

Commenter l'article