web-dev-qa-db-fra.com

Quel schéma de numérotation de version utiliser?

Je recherche un schéma de numérotation des versions qui exprime l’ampleur du changement, en particulier la compatibilité.

Apache APR , par exemple, utilise le schéma de numérotation de versions bien connu

<major>.<minor>.<patch>
example: 4.5.11

Maven suggère un schéma similaire mais plus détaillé:

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Où le schéma de gestion de versions Maven est-il défini? Existe-t-il des conventions pour le qualificateur et le numéro de build? C'est probablement une mauvaise idée d'utiliser Maven mais de ne pas suivre le schéma de version de Maven ...

Quels autres schémas de numérotation de versions connaissez-vous? Quel schéma préféreriez-vous et pourquoi?

schemaversioningmaven
26
deamon

Voici l'algorithme de comparaison de versions Maven actuel , et une discussion de celui-ci. Tant que les versions ne font que croître et que tous les champs, à l'exception du numéro de build, sont mis à jour manuellement, tout va bien. Les qualificatifs fonctionnent comme ceci: si l’un est un préfixe de l’autre, plus long est ancien. Sinon, ils sont comparés alphabétiquement. Utilisez-les pour les pré-versions.

Soutenir l'utilisation du versioning sémantique pour exprimer la compatibilité; major concerne les modifications non compatibles avec la version précédente, mineur pour les fonctionnalités compatibles avec la version précédente, correctif pour les corrections de bogues compatibles avec la version antérieure. Documentez-le pour que les utilisateurs de votre bibliothèque puissent exprimer correctement leurs dépendances. Vos instantanés sont automatisés et ne doivent pas être incrémentés, à l'exception du premier instantané après une publication en raison de la façon dont les préfixes sont comparés.

25
Tobu

Je recommanderais le standard de version sémantique, que le système de gestion de versions Maven semble également suivre. Veuillez vérifier s'il vous plait,

http://semver.org/

En bref, il s’agit de <major>.<minor>.<patch><anything_else>, et vous pouvez ajouter des règles supplémentaires à la partie «autres éléments» qui vous convient. par exemple. -<qualifier>-<build_number>.

23
sixohsix

Pour être complet, je mentionnerai le ancien standard Apple pour les numéros de version . Cela ressemble à version majeure . version mineure . version de bogue . stage . révision non-release . Stage est un code tiré de l'ensemble d (développement), a (alpha), b (bêta) ou fc ( expédition du client final - plus ou moins la même chose que la version candidate, je pense).

Les versions stage et non-release ne sont utilisées que pour les versions ne disposant pas de versions appropriées.

Ainsi, la première version de quelque chose pourrait être 1.0.0. Vous avez peut-être publié un correctif en tant que 1.0.1, une nouvelle version (avec davantage de fonctionnalités) en 1.1, et une réécriture ou une mise à niveau majeure en 2.0. Si vous souhaitez ensuite travailler vers la version 2.0.1, vous pouvez commencer par la version 2.0.1d1, la version 2.0.1d2, puis la version 2.0.1d153 ou ce que cela vous a pris, puis envoyer la version 2.0.1a1 à QA, puis l’approuver 2.0.1a37. , envoyez 2.0.1b1 à certains parieurs consentants, puis après 2.0.1b9 ayant survécu une semaine sur le terrain, gravez 2.0.1fc1 et commencez à obtenir des approbations. Quand 2.0.1fc17 en aurait assez, il deviendrait 2.0.1 et il y aurait beaucoup de réjouissances.

Ce format était suffisamment standardisé pour qu'il y ait un format binaire compact et des routines auxiliaires dans les bibliothèques pour effectuer des comparaisons.

6
Tom Anderson

Après avoir lu de nombreux articles/QA/FAQs/livres, je commence à penser que [MAJOR]. [MINOR]. [REV] est le schéma de versioning le plus utile pour décrire la compatibilité entre les versions de projet (schéma de versioning pour développeur). , ne pas pour le marketing).

MAJEURles modifications sont incompatibles avec les versions antérieures et nécessitent le changement du nom du projet, du chemin d'accès aux fichiers, des GUID, etc.

MINEURles modifications sont compatibles avec les versions antérieures. Marquer l'introduction de nouvelles fonctionnalités.

REVpour la sécurité/les corrections de bugs. Compatible en amont et en aval.

Ce schéma de contrôle de version est inspiré de la sémantique de versioning de libtool _ et d'articles:

http://www106.pair.com/rhp/parallel.html

NOTE: Je recommande également de fournir build/date/custom/quality en tant qu'informations supplémentaires (numéro de build, date de compilation, nom du client, qualité de la version):

Hello app v2.6.34 pour Banque nationale , 2011-05-03 , bêta , build 23545

Mais cette information est not infoing!

4
gavenkoa

Notez qu'un schéma de numéro de version (tel que x.y.0 vs x.y) peut être limité par des facteurs externes.

Considérez que annonce pour Git 1.9 (janvier 2014) } _:

Une version candidate Git v1.9-rc2 est maintenant disponible pour des tests aux endroits habituels.

J'ai entendu des rumeurs selon lesquelles divers outils tiers n'apprécient pas les numéros de version à deux chiffres (par exemple, "Git 2.0") et ont commencé à déranger à gauche et à droite lorsque les utilisateurs installent la v1 .9-rc1.
Bien qu'il soit tentant de se moquer d'eux pour leur hypothèse bâclée, je suis aussi pratique et cela ne me dérange pas d'appeler la prochaine version v1.9.0 pour les aider.

Si nous empruntons cette voie (et que je suis enclin à le faire à ce moment-là), le schéma de gestion des versions sera le suivant:

  • La prochaine version candidate sera v1.9.0-rc3, pas v1.9-rc3;
  • La première version de maintenance pour v1.9.0 sera v1.9.1 (et la Nième sera v1.9.N); et
  • Après la version 1.9.0, la version de fonctionnalité sera v1.10.0 ou v2.0.0, selon l'ampleur du saut de fonctionnalité que nous examinons.
0
VonC