Comment faire des numéros de version?

X. Y. Z. g

Les incréments de g sont instables. (ou RCs) les incréments de z sont stables et signifient des corrections de bugs.
les incréments en y sont stables et signifient de nouvelles fonctionnalités.
les incréments dans x sont stables, version majeure sans rétrocompatibilité à 100%.

J'ai écrit un "guide de style de version" élaboré pour un de mes grands projets. Le projet n'a pas pu se concrétiser, mais le guide de style est toujours disponible en ligne. C'est mon opinion personnelle, peut-être que c'est utile (ou inspirant) pour vous.

Attention, c'est un texte long, et va dans le versionnage des composants par rapport au versionnage des produits et des choses comme ça. Il exprime également des opinions fortes sur certains systèmes de versioning populaires dans la communauté OSS, mais je les ai, donc je les exprime. ;-)

Je ne suis pas d'accord avec L'utilisation du numéro de révision Subversion, par exemple. Vous voudrez peut - être maintenir une version publiée tout en poursuivant le développement dans le tronc, de sorte que vous allez configurer une branche de maintenance-et votre numéro de révision versioning va dans le drain.

Edit: en résumé, il fait la distinction entre les fichiers source de gestion de versions, les composants et le produit Global. Il utilise un système de versoning X. y séparé pour les composants et le produit, avec une belle interdépendance entre les deux qui rend le traçage quelle version de composant appartient à quelle version de produit trivial. Il parle également de la façon de gérer les cycles alpha / bêta / release / patch sans casser le système. En fait, c'est un modus operandi pour tout le cycle de développement, Donc vous voudrez peut-être choisir. ;-)

Edit 2: comme assez de gens ont trouvé mon article utile pour en faire une "bonne réponse", j'ai recommencé à travailler sur l'article. Les versions PDF et LaTeX sont maintenant disponibles, une version complète réécrire y compris une meilleure langue et des graphiques explicatifs suivra dès que je peux trouver le temps. Merci pour vos votes!

Inspirez-vous de Wikipedia: "Software versioning"

Une autre option" nouvelle "et" relativement populaire " est Versioning sémantique

Résumé:

Étant donné un numéro de version majeur.MINEUR.PATCH, incrémenter le:

1. version majeure lorsque vous apportez des modifications d'API incompatibles,
2. version mineure lorsque vous ajoutez des fonctionnalités de manière rétrocompatible, et
3. version PATCH lorsque vous faites corrections de bugs rétrocompatibles.

Des étiquettes supplémentaires pour les métadonnées de pré-version et de génération sont disponibles les extensions de la MAJEURE.MINEUR.Format de PATCH.

Sur la base de mon expérience avec la gestion complexe des dépendances au niveau de la plate-forme d'entreprise et le versioning de version, je suis venu recommander une approche que j'aime appeler Versioning Semi-sémantique.

Fondamentalement, il se construit à partir de Versioning sémantique 2.0 mais n'est pas aussi strict.

Segments De Version Semi-Sémantique:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Format De Segment De Version Primaire:

MARKETTING.MAJEUR.MINEUR.PATCH

Chaque segment devrait permettre alphanumériques, mais les nombres purs sont recommandés pour les changements incrémentiels logiques.

Comme SemVer, je recommande les composants Major, Minor et Patch pour représenter les niveaux de compatibilité inverse, mais je recommande également d'ajouter un composant Marketing. Cela permet aux propriétaires de produits, aux épopées / groupes de fonctionnalités et aux préoccupations commerciales de contourner le composant principal indépendamment des problèmes de compatibilité technique.

Contrairement aux autres réponses, Je ne recommande pas d'ajouter une Build numéro au segment principal. Au lieu de cela, ajoutez un Segment Post-Release après un '+' (ex: 1.1.0.0+build.42). SemVer appelle ces métadonnées de construction, mais je pense que le Segment Post-publication est plus clair. Ce segment est idéal pour déclarer les données de suffixe comme non liées aux informations de compatibilité dans le segment de version primaire . Vos builds d'intégration continue peuvent alors recevoir le numéro de version précédent ajouté avec un numéro de build incrémental qui se réinitialise après chaque version principale (ex: 1.1.0.0 -> 1.1.0.0+construire.1 -> 1.1.0.0+construire.2 -> 1.1.0.1 ). Certaines personnes aiment alternativement mettre le numéro de révision svn ici ou le SHA git commit pour le rendre facile à lier au référentiel de code. Une autre option consiste à utiliser le segment post-release pour les correctifs et les correctifs, qu'il pourrait être utile d'envisager d'ajouter un nouveau composant de version primaire pour cela. Il peut toujours être supprimé lorsque le composant patch est incrémenté, car les versions sont effectivement alignées à gauche et triées.

Dans outre les segments release et post-release, les gens veulent souvent utiliser un Segment Pre-Release pour indiquer des pré-versions presque stables comme les alphas, les bêtas et les candidats release. L'approche SemVer à cela fonctionne bien, mais je recommande de séparer les composants numériques des classificateurs alphanumériques(ex: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalement, vous cognez le segment de version en même temps que l'ajout du segment post-version, puis supprimez le segment pré-version lors de la prochaine bump leur segment de version primaire (ex: 1.0.1.2 - > 1.2.0.0-RC.1 -> 1.2.0.0). Les segments de pré-version sont ajoutés pour indiquer que la version de la version est à venir, généralement juste un ensemble fixe de fonctionnalités pour des tests et un partage plus approfondis qui ne changent pas de minute en minute en fonction de plus de commits.

La beauté d'avoir tout cela défini sémantiquement d'une manière qui couvre presque tous les cas d'utilisation est que vous pouvez les analyser, les trier, les comparer et les incrémenter de manière standard. C'est particulièrement important lors de l'utilisation de systèmes CI pour des applications complexes avec beaucoup de petits composants versionnés indépendamment (comme les micro-services) chacun avec leurs propres dépendances gérées.

Si vous êtes intéressé, j'ai écrit un analyseur semi-sémantique dans ruby . Je devais non seulement utiliser ce modèle, mais être capable de gérer d'autres applications qui l'utilisaient.

A. B. C. d

Incréments : lorsque
- d: corrections de bugs
- c : maintenance, p.ex. amélioration des performances
- b: de nouvelles fonctionnalités
- un: modification de l'architecture

Le obligatoire est le plus à gauche par exemple s'il y a par exemple une nouvelle fonctionnalité et un bug corrigé, Il suffit d'incrémenter b.

Il est assez populaire de nos jours d'utiliser simplement le numéro de révision Subversion.

Les "numéros de Version" relèvent de votre système de contrôle de version interne. Les numéros de version sont une question différente (et doivent être conservés différents).

S'en tenir à un simple majeur.Système de version mineure (comme v1. 27), où MAJOR est le niveau de compatibilité (version 2.x est incompatible avec la version 1 ou au moins très différent de celle-ci.x) et mineur est vos versions de correction de bugs ou des améliorations mineures. Tant que vous suivez le format X. Y, Vous pouvez également utiliser D'autres systèmes comme YEAR.Mois (2009.12) ou AN.Version (2009.3). Mais vraiment, vous êtes probablement mieux coller à MAJOR.Mineur sauf si vous avez une bonne raison de ne pas le faire.

N'utilisez absolument rien qui ne correspond pas au format X. Y, car cela rendra la tâche difficile pour les distributions,les sites d'annonces, etc. travailler avec vous, et cela seul pourrait sérieusement affecter la popularité de votre projet.

Utilisez des branches et des balises dans votre système de contrôle de version (de préférence distribué) pour marquer des numéros de version internes spécifiques Mineurs respectivement.

Et oui, 1.0 devrait être stable. Toutes les versions doivent être stables, sauf si elles sont marquées alpha, bêta ou RC. Utilisez Alphas Pour connu cassé et incomplet. Bêtas Pour connu-cassé. RCs pour "Essayez-le; vous allez probablement repérer les choses que nous avons manquées". Tout ce qui ne l'est pas devrait (idéalement, bien sûr) être testé, bien connu, avoir un manuel à jour, etc.

Si C'est dans SVN alors pourquoi ne pas utiliser le numéro de révision SVN?

Si vous regardez en bas à droite de cette page web, vous verrez le numéro de version de Stack Overflow qui est le numéro de révision SVN.

La gestion des versions dépend de vous; je mettrais 1.0 sur la première version dans laquelle j'avais confiance. Vous pouvez la suivre rapidement avec d'autres versions, car certains éditeurs de logiciels ont donné 1.0 une mauvaise réputation.

Vous voulez un moyen de lier le numéro de version exacte de construire utilisé, mais probablement, vous voulez qu'il soit agréable et simple pour vos utilisateurs finaux. Pensez à utiliser des numéros de version standard et à étiqueter le référentiel SVN avec le numéro de version inclus.

Tout en allant avec le numéro de révision Subversion est agréable et simple, il supprime les informations du numéro de version. Les utilisateurs pourraient considérer cela comme une mauvaise chose.

Je suppose que votre webapp aura une sorte de procédure de déploiement, de sorte que chaque révision de Subversion n'est pas réellement publiée. Comme il est impossible de "l'extérieur" (du point de vue de l'utilisateur) de déterminer quand les versions sont effectuées, et combien de révisions le code subira entre eux, il fait les nombres presque aléatoires. Ils vont augmenter, et je suppose qu'il est possible de supposer une certaine distance par rapport à la comparaison de deux révisions, mais pas beaucoup.

Les numéros de version classiques ont tendance à" dramatiser " les versions, de sorte que les utilisateurs peuvent construire une sorte d'attente. Il est plus facile de penser "j'ai la version 1.0, maintenant la version 1.1 est sortie en ajoutant ceci et cela, cela semble intéressant "que de penser" hier nous avons couru donc la révision 2587, aujourd'hui c'est 3233, ça doit être beaucoup mieux!".

Bien sûr, cette dramatisation peut être gonflée aussi, avec des entreprises qui choisissent des numéros de version qui sont destinés à paraître plus intéressant que ce qui est motivé par les différences réelles dans le produit, je suppose que les compteurs de numéro de révision un peu.

Schéma de Version: [majeur].[mineur].[devrel][marque]
[majeur]: incrément si vous avez un changement radical dans le développement.
[mineur]: incrément si vous avez un changement mineur dans le développement.
[devrel]: incrémenter si vous avez une correction de bug. Réinitialiser à zéro si majeur++ ou mineur++.
[marque]: a, b ou rc: un est une version alpha, b est en version bêta et rc est une version release candidate. Notez que les versions comme 1.3.57 A ou 1.3.57 B ou 1.3.57 rc est avant la version 1.3.57. Commencez à 0.0.0.

Nous avons passé beaucoup trop de temps à décider quand incrémenter la version majeure. Certains magasins le feraient rarement, donc vous auriez des versions comme 1.25.3 et d'autres le feraient pour toujours en vous donnant 15.0

J'en ai marre et j'ai convaincu tout le monde que le numéro de la version majeure n'est que l'année et que le mineur n'est qu'une version séquentielle dans l'année. Les utilisateurs semblaient l'aimer et c'est une évidence de venir avec la prochaine version nombre.

Année.Publier.construire

• année = année en cours
• version = séquence de nombre de diffusions publiques avec nouvelle fonctionnalité-Réinitialiser à 1 chaque année
• build = incrémenté pour bug corrections et versions internes

Modifier

** Maintenant, c'était pour une application qui a été continuellement améliorée **

Cela ne fonctionnerait probablement pas pour les applications commerciales où il est important d'avoir des versions majeures à différents moments de l'année pour le marketing et des raisons financières.

J'ai très peu d'expérience dans la région. Cependant, voici ce que je ferais:

1. Choisissez un schéma pour numéroter les révisions et respectez-le. Être cohérent.
2. Chaque changement de version devrait représenter un changement significatif. La taille d'un changement est importante et les niveaux de changement qui sont reflétés dans le numéro de version sont à vous.

Bien sûr, vous pouvez simplement utiliser le numéro de révision svn --- comme beaucoup d'autres ont suggéré!!!

J'espère que cela aider.

La raison pour laquelle cette question Existe est que nous n'avons pas un seul moyen convenu de gérer la configuration.

La façon dont j'aime faire le numéro de version est juste incrémenter l'entier de 1. Je ne veux pas d'un numéro de version en plusieurs parties que je devrai expliquer ou documenter. Et je ne veux pas utiliser SVN rev number car cela nécessitera également des explications.

Vous auriez besoin de scripts de publication au-dessus de SVN pour que cela se produise

Nous utilisons un majeur simple.mineur.syntaxe julian_date.

Où:

• major - première version est 1 et puis quand nous introduisons de nouvelles fonctionnalités majeures ou des changements si importants qu'ils ne sont pas rétrocompatibles augmenter ce nombre.
• minor-les principales versions de milestone. Pour chaque construction poussée par la production, ce nombre augmente.
• julian_date - le jour Julien la construction a été poussée à QA.

Exemple de la première version poussée à QA sur 1/15 est - > 1.0.015
Exemple de la première version poussée à la Production sur 3/4 est - > 1.1.063

Ce n'est pas parfait, mais pratique car nous poussons les builds vers QA presque tous les jours.

Quelques bonnes informations ici:

Quand changer les Versions de fichier/assemblage

Tout d'abord, les versions de fichiers et les versions d'assemblage ne doivent pas nécessairement coïncider les unes avec les autres. Je recommande que les versions de fichiers changent à chaque build. Mais, ne changez pas les versions d'assemblage avec chaque build juste pour que vous puissiez faire la différence entre deux versions du même fichier; utilisez la version du fichier pour cela. Décider quand changer les versions d'assemblage prend une discussion sur les types de builds à considérez: expédition et non-expédition.

Builds Non-Expédition En général, je recommande de garder les versions d'assemblage non-expédition les mêmes entre les versions d'expédition. Cela évite les problèmes de chargement d'assemblage fortement nommés dus à des discordances de version. Certaines personnes préfèrent utiliser la stratégie publisher pour rediriger les nouvelles versions d'assembly pour chaque build. Je recommande cependant de ne pas le faire pour les constructions non-maritimes: cela n'évite pas tous les problèmes de chargement. Par exemple, si un partenaire x-copie votre application, il peut Je ne sais pas installer la stratégie de l'éditeur. Ensuite, votre application sera cassée pour eux, même si cela fonctionne très bien sur votre machine.

Mais, s'il y a des cas où différentes applications sur la même machine doivent se lier à différentes versions de votre assembly, je recommande de donner à ces builds différentes versions d'assembly afin que la bonne pour chaque application puisse être utilisée sans avoir à utiliser LoadFrom/etc.

Construction D'Expédition Quant à savoir si c'est une bonne idée de changer cette version pour expédition construit, cela dépend de la façon dont vous voulez que la liaison fonctionne pour les utilisateurs finaux. Voulez-vous que ces builds soient côte à côte ou en place? Y'a beaucoup de changements entre les deux versions? Vont-ils pour casser certains clients? Ne vous vous souciez qu'il se casse (ou voulez-vous forcer les utilisateurs à utiliser vos mises à jour importantes)? Si oui, vous devriez envisager d'incrémenter la version d'assemblage. Mais, là encore, considérez que faire cela trop de fois peut encombrer le disque de l'utilisateur avec des assemblages obsolètes.

Lorsque Vous Modifiez Vos Versions D'Assemblage Pour changer les versions codées en dur à la nouvelle, je recommande de définir une variable à la version dans un fichier d'en-tête et de remplacer le codage en dur dans les sources par la variable. Ensuite, exécutez un pré-processeur pendant la construction pour mettre dans la bonne version. Je recommande de changer les versions juste après l'expédition, pas juste avant, afin qu'il y ait plus de temps pour attraper les bugs en raison du changement.

Ou pour utiliser votre numéro de version' thought ' comma subversion number.. z. B.:

1.0.101 / / révision 101, version

Ou 1.0.101-090303 // avec la date de sortie, j'utilise ceci