Quelle «convention de dénomination de version» utilisez-vous? [fermé]

Des conventions de dénomination de version différentes sont-elles adaptées à différents projets? Qu'est ce que vous utilisez et pourquoi?

Personnellement, je préfère un numéro de build en hexadécimal (par exemple, 11BCF), qui devrait être incrémenté très régulièrement. Et pour les clients, un numéro de version simple à 3 chiffres, à savoir 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Je suis rarement d'accord avec Jeff Atwood, mais j'ai tendance à suivre son opinion sur la convention .NET relative à la numérotation des versions .

(Version majeure). (Version mineure). (Numéro de révision). (Numéro de build)

Le plus souvent, pour des projets personnels, je trouve cela excessif. Les rares fois où j'ai travaillé sur des projets de grande envergure, tels que des moteurs de recherche en C #, je suis resté fidèle à cette convention et j'ai pu l'utiliser efficacement en tant que suivi interne.

Le versioning sémantique ( http://semver.org/ ) mérite une mention ici. Il s’agit d’une spécification publique pour un schéma de version, sous la forme [Major].[Minor].[Patch]. La motivation de ce schéma est de communiquer le sens avec le numéro de version.

Je ne l'utilise pas mais j'ai vu et c'est une structure intéressante:

Year.Month.Day.Build

Auto expliqué

J'essaie d'utiliser la stratégie RubyGems Rational Versioning dans laquelle:

• Le numéro de version majeure est incrémenté lorsque la compatibilité binaire est rompue
• Le numéro de version mineur est incrémenté lorsque de nouvelles fonctionnalités sont ajoutées.
• Le numéro de build change pour les corrections de bugs.

Voici une approche très fine de la numérotation des versions:

• N.x.K, où Net Ksont des entiers. Exemples: 1.x.0, 5.x.1, 10.x.33. Utilisé pour les constructions intermédiaires .
• N.M.K, Où N, Met Ksont des nombres entiers. Exemples: 1.0.0, 5.3.1, 10.22.33. Utilisé pour les dégagements .
• N.x.x, où Nest un entier. Exemple: 1.x.x. Utilisé pour les branches de support .
• N.M.x, où Net Msont des entiers. Exemple: 1.0.x. Utilisé pour les branches de libération .

Voici l'image pour une illustration simple de l'approche de numérotation des versions:

PAsignifie pré-alpha A signifie alpha B signifie bêta AR signifie libération alpha BR signifie libération bêta RC signifie libération candidate ST signifie stable

Les avantages d’une telle approche de numérotation des versions sont les suivants:

• Il représente les spécificités du cycle de vie du développement logiciel agile .
• Il prend en compte les spécificités de la structure du référentiel de code source .
• C'est explicite pour ceux qui se sont habitués aux modèles. Chaque motif représente un artefact différent. De tels modèles peuvent être facilement analysés et utilisés à d'autres fins, telles que le suivi des problèmes.
• Ensemble de modèles de gestion de versions, qui de base pour l’approche de gestion de version décrite peut être utilisé pour la collecte de statistiques et la planification .
• Il est axé sur les concepts de maturité et de niveau de qualité . Très souvent, des numéros de version tels que 1.0.0 sont attribués sans grande nécessité (lorsque le logiciel est en alpha profond). L’approche de numérotation de version présentée permet d’établir plusieurs niveaux de maturité. Dans le cas le plus simple, il n’aura que deux niveaux: intermédiaire build ( N.x.K) et release ( N.M.K). La publication signifie que le logiciel avec le numéro de version complet ( N.M.K) a subi un processus quelconque de gestion de la qualité au sein de la société, de l’organisation ou de l’équipe du fournisseur.
• C'est une preuve de la nature agile du développement et des tests.
• Encourage l'approche modulaire de la structure et de l'architecture logicielles.

Il existe également un diagramme plus complexe représentant l'approche des versions en détail. Vous pouvez également trouver des diapositives de présentation utiles décrivant la transition vers l'approche de version et l' application SCMFViz illustrant les principes de base de l'approche de numérotation de version. Les diapositives de la présentation expliquent également pourquoi il est important de suivre la même approche de gestion des versions tout au long du projet.

Personnellement, mon attitude à l’égard de l’utilisation de la version de la date au lieu des numéros de version réels suppose que les développeurs du logiciel avec des versions datées

• Ne sais rien du cycle de vie du développement logiciel . Le développement est généralement agile et itératif. L’approche de numérotation des versions doit représenter la nature itérative du processus de développement logiciel.
• Ne vous souciez pas de la qualité du logiciel . Le contrôle et l'assurance de la qualité sont agiles et itératifs. Tout comme le développement. Et le numéro de version doit être la preuve de la nature agile et itérative du développement et du contrôle / assurance de la qualité.
• Ne vous souciez pas de l'architecture ou de l' idée de leur application. Le numéro de version majeure ( Nin N.M.K) est responsable à la fois de la solution architecturale et du principe sous-jacent de l'application. Le numéro de version principale Ndoit être modifié en fonction des modifications apportées à l'architecture ou des principales idées et principes de fonctionnement / fonctionnement.
• Ne pas contrôler leur base de code . Il n'y a probablement qu'une seule branche (tronc) et il est utilisé pour tout. Personnellement, je ne pense pas que ce soit correct, car cela encourage Codebase à devenir un grand dépotoir.

Cette approche peut sembler un peu controversée, mais j'estime qu'il s'agit du moyen le plus simple de donner aux logiciels les numéros de version appropriés.

Pour chaque version majeure que vous publiez, il n’est pas rare d’avoir une version opérationnelle que vous appelez en interne. Par exemple, lors de mon dernier travail, nous avons fait référence à une version majeure avec la convention de dénomination suivante inspirée par Ubuntu:

[état maladif] [nom de l'animal allitératif]

Ce qui a donné des noms tels que " Lamproie ", " Wombat blessé " et " Fourmilier asthmatique ".

Assurez-vous, à moins que le nom ne soit vraiment cool, qu'il ne soit pas divulgué à vos clients.

Generation.Version.Revision.Build (9.99.999.9999)

La génération change rarement. Seul un gros produit sur le produit: DOS -> Windows, réingénierie complète.

La version est destinée aux gros changements incompatibles, aux nouvelles fonctionnalités, aux changements de paradigmes spécifiques du logiciel, etc.

La révision est souvent effectuée (fonctionnalités mineures et correction de bugs).

Construire est une information interne.

git describefournit une extension intéressante à la convention de numérotation que vous avez choisie. Il est assez facile d'intégrer cela dans votre processus de construction / conditionnement / déploiement.

Supposons que vous nommez les versions ABC marquées (major.minor.maintenance). git describesur un commit donné, trouvera l'ancêtre balisé le plus récent du commit, puis ajoutera le nombre de commits depuis et l'abréviation SHA1 du commit:

1.2.3-164-g6f10c

Si vous utilisez actuellement l'une des versions, vous n'aurez que le tag (1.2.3).

Cela a l'avantage de vous permettre de savoir exactement de quelle source vous avez construit, sans avoir à numéroter vous-même chaque construction.

Major.Minor.Public (build) [alpha / bêta / essai], tel que "4.08c (1290)"

• Major étant le numéro de version majeur (1, 2, 3 ...)
• Mineure étant une version mineure à 2 chiffres (01, 02, 03 ...). Généralement, le chiffre des dizaines est incrémenté lorsque de nouvelles fonctionnalités importantes sont ajoutées, celles destinées uniquement aux corrections de bugs.
• Public étant la version publique de la construction (a, b, c, d, e), qui diffère souvent de la version mineure si une version mineure n'est jamais publiée en tant que mise à jour publique.
• build, étant le numéro de build réel que le compilateur garde en mémoire.
• avec TRIAL, ALPHA, BETA X ou RC X ajoutés pour ces cas particuliers.

Je préfère les numéros de version qui attribuent une signification sémantique. Tant que vous pouvez utiliser le numéro de version pour suivre les bogues signalés avec une version particulière concernant les modifications survenues dans le code source (et dans votre système de gestion des activités), vous utilisez probablement la bonne méthode.

J'utilise .NET alors je suis coincé avec le système de numérotation des versions .NET mais j'essaie de donner un sens sémantique aux nombres, donc avec

major.minor.build.revision

• majeur = (jusqu'au projet)
• mineur = (jusqu'au projet)
• build = numéro de construction de Hudson (vous pouvez utiliser TeamCity ou TeamBuild, etc. ici)
• révision = révision de subversion ou de bazar (selon le projet et son utilisation)

Nous nous assurons toujours que le numéro de version est visible d'une manière ou d'une autre (avec nos programmes basés sur la console de traitement par lots, il est imprimé sur une console et un fichier journal, les applications Web se trouvent généralement dans la barre de menus en haut).

Ainsi, si les clients signalent des problèmes, nous pouvons utiliser le numéro de version pour déterminer s’ils utilisent la dernière version et le nombre de problèmes rencontrés avec des versions particulières.

Tout est question de traçabilité!

Nous utilisons Major.Minor.Build # .YYMMDD [suffixe], car nous n’effectuons généralement qu’une génération de production un jour donné (mais nous utilisons le suffixe ab / c / d s’il en existe plusieurs) et le YYMMDD donne aux utilisateurs / clients / gestion une indication de l'âge de la construction, contrairement à 6.3.1389.

Les nombres majeurs augmentent avec les caractéristiques du produit significatives (payantes).

Les nombres mineurs augmentent avec les corrections / améliorations (mise à jour gratuite).

Construire augmente toujours; pas tous construit navire, donc ce n'est pas une progression linéaire.

Les numéros de version doivent contenir suffisamment d'informations pour éviter les conflits et la résolution d'un bogue dans les problèmes de type de version incorrects, mais ne doivent pas contenir d'informations supplémentaires non pertinentes.

Par exemple, si vous utilisez la date, les clients peuvent dire qu'ils ont une version plus ancienne et les correctifs des anciennes versions peuvent avoir des versions confuses.

Personnellement, j'aime les versions sémantiques :

• Les rejets sont Major. Minor.Patch
• Patch incrémente chaque fois que vous publiez une construction.
• Minor incrémente à chaque fois qu'une fonctionnalité rétrocompatible est ajoutée.
• Major incrémente lorsque les nouvelles fonctionnalités ne sont pas compatibles avec les versions antérieures.
• Lorsque Major== 0 vous êtes en version alpha / préliminaire. Major> = 1 sont vos publications publiques.
• Les chiffres les plus bas sont réinitialisés à 0 chaque fois que vous incrémentez.

  1.5.3-> 1.5.4(correction de bogue) -> 1.6.0(fonctionnalité mineure) -> 2.0.0(changement radical)

              1.0.0
                |
              1.0.1
                |
(public 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (public 1.1)
                |
(public 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (public 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zest notre numéro de version interne. X.Yest le numéro de version publique, celui qui a un sens pour nos clients. Lorsqu'une X.Y.Zversion devient publique, il n'y aura jamais de X.Y.(Z+1)version: la version publique est toujours la dernière de la série.

X est incrémenté quand une version majeure est publiée.

Y est utilisé pour les branches de maintenance de ces versions majeures, uniquement pour les corrections de bugs.

Zest utilisé en interne et n'a pas de signification fixe. Jusqu'à présent, je crée une nouvelle Zversion quand je pense que l'application possède un ensemble de fonctionnalités intéressantes à montrer aux non-développeurs et est relativement stable. De cette façon, je peux montrer une démo de la "dernière bonne version connue" de l'application quand quelqu'un le demande. Dans un proche avenir, je prévois d'utiliser les Zversions numériques pour nommer une "cible" de fonctionnalités, dans notre bugtracker.

En remarque, nous utilisons maven (avec la releasecommande) pour incrémenter le numéro de version. Donc, il y a aussi des X.Y.Z-SNAPSHOTversions (qui indiquent n'importe quelle version entre X.Y.(Z-1)et X.Y.Z).