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

107

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.
parler
la source

Réponses:

45

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.

Mike B
la source
1
Cela a tendance à suivre le schéma que j'ai vu utilisé avec succès dans de nombreux projets, grands ou petits. C'est très efficace.
luis.espinal
1
Quel est le lien entre le "numéro de build" et "l'identifiant de l'ensemble de modifications (hachage)"? Est-ce que cela fait partie du hash, incrémental ou autre chose?
Jace Browning
@ Jace, où je travaille, nous utilisons Mercurial et désactivons le numéro de changeset. Nous ne faisons que pousser vers / extraire depuis un seul référentiel, le nombre n’est donc pas propre à la caisse spécifique. Nous avons ensuite [majeur]. [Mineur]. [Changeset] en conséquence (bien que les nombres majeurs et mineurs soient souvent plus marketing que des indicateurs de progrès depuis la dernière version).
Wai Ha Lee
Si vous appelez ToString () sur une structure de version .NET, la construction sera le troisième numéro, pas la révision. Comme vous pouvez le voir avec ce script PowerShell:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
Joel McBeth le
Est-ce que "numéro de build" implique que ce ne sont que des modifications mineures comme des corrections de bugs? Toute nouvelle fonctionnalité devrait-elle au moins avoir son propre numéro de révision?
Kyle Delaney
90

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.

M. Dudley
la source
Surpris cela ne devient pas plus d'amour.
Mark Canlas
J'étais un peu en retard à la fête ... J'ai ajouté cette réponse 9 mois après la question initiale. ;-)
M. Dudley le
Cela semble être la même chose que la politique RubyGems Rational Versioning que j'ai mentionnée ci-dessous, mais elle est mieux formalisée.
Ken Bloom
@MarkCanlas ne reçoit pas plus d'amour parce qu'il attache des idées spécifiques à ce qui constitue une version majeure / mineure / patch. Il parle des API, ce qui est un peu ... bizarre
Rudolf Olah
5
SemVer est destiné aux API de version, et non aux logiciels destinés à l'utilisateur: "Les logiciels utilisant le versioning sémantique DOIVENT déclarer une API publique." Donc techniquement, vous ne pouvez pas utiliser SemVer sans une API publique. Cependant, il peut être judicieux d'adopter quelque chose de similaire à SemVer pour le contrôle de version des applications orientées utilisateur.
Ajedi32
33

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

Year.Month.Day.Build

Auto expliqué

Maniero
la source
4
Et vous savez toujours à quel point votre code est frais ..! :)
Lipis
3
Ceci est également similaire aux numéros de version d'Ubuntu. Ils font l'année. Exemples: 10.04 et 10.10
Brad Cupit
5
Il est à noter que cela ne fonctionne que pour un système qui n'a pas de problèmes de compatibilité (un site Web), ou qui a toujours une incompatibilité (une version Ubuntu).
jkerian
1
@ jkerian, pourquoi la compatibilité est-elle importante?
AviD
12
@AviD: Je ne comprends pas très bien pourquoi vous posez cette question, car presque toutes les autres réponses à cette question montrent des systèmes de version qui incluent des informations de compatibilité. Votre choix dépend des informations que vous souhaitez enregistrer avec vos numéros de version. Pour les besoins de mon propos, une date n’a fondamentalement aucune signification (le fait de commencer par v1 et d’augmenter chaque version serait une amélioration). Avez-vous déjà une branche? est-ce que vous publiez un "nouveau patch sur l'ancien code" en même temps que "nouvelle version"? Mais pour quelque chose comme un site Web ou un système d'exploitation, un système basé sur la date semble tout à fait approprié.
jkerian
13

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.
Ken Bloom
la source
2
Ceci est essentiellement connu sous le nom de "Semantic Versioning": semver.org
Patrice M.
2
@PatriceM. Merci de partager ce lien. semver.org n'existait pas quand j'ai écrit cette réponse.
Ken Bloom
10

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:

Numérotation de version agile

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.

altern
la source
Premier lien en bas ...............
Pacerier le
8

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.

Jesse C. Slicer
la source
2
On dirait une utilisation inefficace du temps et de l'énergie .............
Pacerier le
10
Alors laissait ce commentaire, mais cela ne vous a pas arrêté.
Jesse C. Slicer le
C'est toute une magnitude inférieure ......
Pacerier
7

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.

Maniero
la source
Bonne idée. Où avez-vous eu l'idée de "génération"?
Pacerier
6

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.

Cascabel
la source
2

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.
Grand maître b
la source
2

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é!

Jeffrey Cameron
la source
1

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.

JBRWilkinson
la source
1

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)

De cette façon, si quelqu'un utilise, par exemple, une version, 1.5.3il peut indiquer d'un coup d'œil qu'il est possible d'effectuer une mise à niveau pour 1.5.4obtenir les correctifs, ce 1.6.0qui ajouterait des fonctionnalités et ne devrait pas être mis à niveau 2.0.0(du moins sans gérer les modifications).

Keith
la source
Semver ne fonctionne que pour les API. Pas de produits.
Pacerier
@ Pacerier pourriez-vous expliquer pourquoi?
Keith
@ Pacerier, cela ne signifie pas que vous ne pouvez pas utiliser ce modèle pour la numérotation des versions.
Keith
0
              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).

barjak
la source