Quelle «convention de dénomination de version» utilisez-vous?
Les différentes conventions de dénomination des versions 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), cela devrait être incrémenté très régulièrement. Et puis pour les clients un simple numéro de version à 3 chiffres, soit 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 complètement avec Jeff Atwood, mais j'ai tendance à suivre son opinion sur la convention .NET de la numérotation des versions .
(Version majeure). (Version mineure). (Numéro de révision). (Numéro de version)
Plus souvent qu'autrement, pour les projets personnels, je trouve cela exagéré. Les quelques fois où j'ai travaillé sur des projets importants comme les moteurs de recherche en C #, je suis resté fidèle à cette convention et j'ai pu l'utiliser efficacement comme traqueur interne.
La version 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 de [Major].[Minor].[Patch]. La motivation de ce schéma est de communiquer la signification avec le numéro de version.
Je ne l'utilise pas mais j'ai vu et c'est une structure intéressante:
Année.Mois.Jour.Construire
S'explique.
J'essaie d'utiliser RubyGems Rational Versioning policy dans lequel:
- Le numéro de version majeur 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 version change pour les corrections de bogues.
Voici une approche très fine de la numérotation des versions:
N.x.K, oùNetKsont des entiers. Exemples:1.x.0,5.x.1,10.x.33. Utilisé pour versions intermédiaires.N.M.K, oùN,MetKsont des entiers. Exemples:1.0.0,5.3.1,10.22.33. Utilisé pour versions.N.x.x, oùNest un entier. Exemple:1.x.x. Utilisé pour branches de support.N.M.x, oùNetMsont des entiers. Exemple:1.0.x. Utilisé pour libérer les branches.
Voici l'image pour une illustration simple de l'approche de numérotation des versions:
PA signifie pré-alpha A signifie alpha B signifie beta AR signifie alpha-release BR signifie version bêta RC signifie libérer le candidat ST signifie stable
Les avantages d'une telle approche de numérotation des versions sont les suivants:
- Il représente les spécificités de cycle de vie de développement logiciel agile.
- Il prend en compte les spécificités de 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. Ces 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 des versions, qui de base pour l'approche de gestion des versions décrite peut être utilisé pour collecte de métriques et planification.
- Il est axé sur les concepts de maturité et niveau de qualité. Très souvent, des numéros de version tels que 1.0.0 sont attribués sans trop de nécessité (lorsque le logiciel est en alpha profond). L'approche de numérotation des versions présentées permet d'établir plusieurs niveaux de maturité. Dans le cas le plus simple, il n'aura que deux niveaux: build intermédiaire (
N.x.K) et relâchez (N.M.K). Release signifie que le logiciel avec le numéro de version complet (N.M.K) a subi une sorte de processus de gestion de la qualité au sein de la société/organisation/équipe fournisseur. - C'est une preuve de nature agile à la fois de développement et de test.
- Encourage approche modulaire pour la structure et l'architecture du logiciel.
Il y a aussi plus complexe diagramme représentant l'approche de versioning en détails. Vous pouvez également trouver utile diapositives de présentation décrivant la transition vers l'approche de versioning et SCMFViz application illustrant les principes de base de l'approche de numérotation de version. Les diapositives de présentation expliquent également pourquoi il est important de s'en tenir à la même approche de versioning tout au long de la vie du projet logiciel.
Personnellement, mon attitude envers l'utilisation de version de date au lieu de vrais numéros de version suppose que les développeurs du logiciel avec des versions datées:
- Ne rien savoir 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é.
- Peu importe l'architecture ou l'idée de leur application. Numéro de version principale (
NdansN.M.K) est à la fois responsable de la solution architecturale et du principe sous-jacent de l'application. Le numéro de version majeureNdoit être modifié en fonction des changements d'architecture ou des changements des idées et principes majeurs de son fonctionnement/fonctionnement. - Ne contrôlez pas leur base de code . Il n'y a probablement qu'une seule branche (tronc) et elle est utilisée pour tout. Personnellement, je ne pense pas que ce soit juste car cela encourage la base de code à devenir un grand dépotoir.
Cette approche peut sembler un peu controversée, mais je pense que c'est le moyen le plus simple de donner des numéros de version appropriés au logiciel.
Pour chaque version majeure que vous publiez, il n'est pas rare d'avoir une version de travail 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 nommage inspirée d'Ubuntu suivante:
[état maladif] [nom de l'animal allitératif]
Qui a donné des noms tels que "Lamproie lamproie", "Wounded Wombat" et "Asthmatic Anteater".
Assurez-vous, sauf si c'est un nom vraiment cool, qu'il ne coule pas à vos clients.
Generation.Version.Revision.Build (9.99.999.9999)
La génération change rarement. Seul un gros tournant sur le produit: DOS -> Windows, réingénierie complète.
La version est pour de grands changements incompatibles, de nouvelles fonctionnalités, des changements sur certains paradigmes spécifiques sur les logiciels, etc.
La révision est souvent effectuée (fonctionnalités mineures et correction de bugs).
La construction est une information interne.
git describe fournit une belle extension à la convention de numérotation que vous avez choisie. Il est assez facile d'intégrer cela dans votre processus de construction/empaquetage/déploiement.
Supposons que vous nommiez vos versions de version balisées A.B.C (major.minor.maintenance). git describe sur un commit donné trouvera l'ancêtre balisé le plus récent du commit, puis clouera sur le nombre de commits depuis et le SHA1 abrégé du commit:
1.2.3-164-g6f10c
Si vous êtes actuellement dans l'une des versions, bien sûr, vous n'aurez que le tag (1.2.3).
Cela a l'avantage de vous permettre de savoir exactement à partir de quelle source vous avez construit, sans avoir à numéroter vous-même chaque construction.
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 aux changements survenus dans le code source (et dans votre système de gestion des activités), vous utilisez probablement la bonne méthode.
J'utilise .NET donc je suis coincé avec le système de numérotation des versions .NET mais j'essaie de donner un sens sémantique aux nombres avec
major.minor.build.revision
- majeur = (jusqu'au projet)
- mineur = (jusqu'au projet)
- build = numéro de build de Hudson (vous pouvez utiliser TeamCity ou TeamBuild, etc. ici)
- revision = révision Subversion ou Bazaar (en fonction du projet et de 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 une console par lots, il est imprimé sur la console et un fichier journal, avec des applications Web dans la barre de menus en haut en général)
De cette façon, si les clients signalent des problèmes, nous pouvons utiliser le numéro de version pour suivre s'ils utilisent la dernière version et le nombre de problèmes que nous avons rencontrés avec des versions particulières.
Tout est question de traçabilité!
Major.Minor.Public (build) [alpha/beta/trial], tel que "4.08c (1290)"
- Major étant le numéro de version principal (1, 2, 3 ...)
- Minor étant une version mineure à 2 chiffres (01, 02, 03 ...). En règle générale, le chiffre des dizaines est incrémenté lorsque de nouvelles fonctionnalités importantes sont ajoutées, celles des corrections de bugs uniquement.
- Public étant la version publique de la build (a, b, c, d, e), qui est souvent différente 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 dont le compilateur garde la trace.
- avec TRIAL, ALPHA, BETA X ou RC X en annexe pour ces cas particuliers.
Nous utilisons Major.Minor.Build # .YYMMDD [suffixe], car nous ne faisons généralement qu'une seule production en un jour donné (mais utilisez le suffixe ab/c/d s'il y en a plusieurs) et le YYMMDD donne aux utilisateurs/clients/gestion une indication de l'âge de la construction, où 6.3.1389 ne le fait pas.
Les nombres majeurs augmentent avec les fonctionnalités importantes du produit (payantes).
Les nombres mineurs augmentent avec les corrections/améliorations (mise à jour gratuite).
Build augmente toujours; tous les vaisseaux ne sont pas construits, donc ce n'est pas une progression linéaire.
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.Z Est notre numéro de version interne. X.Y Est le numéro de version publique, celui qui a un sens pour nos clients. Lorsqu'une version X.Y.Z Devient publique, il n'y aura jamais de version X.Y.(Z+1): la version publique est toujours la dernière de la série.
X est incrémenté lorsqu'une version majeure est publiée.
Y est utilisé pour les branches de maintenance de ces versions majeures, uniquement pour les corrections de bogues.
Z est utilisé en interne et n'a pas de signification fixe. Jusqu'à présent, je crée une nouvelle version de Z quand je pense que l'application a 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 en demande une. Dans un futur proche, je prévois d'utiliser les versions numériques Z pour nommer une "cible" de fonctionnalités, dans notre bugtracker.
En remarque, nous utilisons maven (avec la commande release) pour incrémenter le numéro de version. Il existe donc également des versions de X.Y.Z-SNAPSHOT (Qui indiquent toute version entre X.Y.(Z-1) et X.Y.Z).