Comment faire les numéros de version?

Question

Mon entreprise fabrique un produit. Cela va être mis à jour par SVN. Il s’agit d’une application Web, donc il n’existera jamais de version qui n’aurait aucune fonctionnalité et qui pourrait donc toujours être qualifiée de bêta. Mais puisqu'il s'agira d'un produit d'entreprise, je ne souhaite vraiment pas la "surveillance instable". Ici. Alors, comment feriez-vous pour la gestion des versions? Est-ce que 1.0 est stable? La date de construction doit-elle être dans le numéro de version? Dites-moi ce que vous en pensez!

Answer 1

[ majeur ]. [ mineur ]. [ publication ]. [ créer ]

majeur : vraiment une décision marketing. Êtes-vous prêt à appeler la version 1.0? La société considère-t-elle qu'il s'agit d'une version majeure pour laquelle les clients pourraient avoir à payer davantage, ou s'agit-il d'une mise à jour de la version majeure actuelle qui peut être gratuite? Moins de décision de R & D et plus de décision de produit.

mineur : commence à 0 chaque fois que majeur est incrémenté. +1 pour chaque version rendue publique.

release : vous augmentez ce nombre chaque fois que vous atteignez un stade de développement et que vous publiez le produit, même en interne (p. ex. au contrôle qualité). Ceci est particulièrement important pour la communication entre les équipes de l'organisation. Inutile de dire que ne publiez jamais deux fois (même en interne) le même «communiqué». Réinitialiser à 0 en mineur ++ ou majeur ++.

build : peut être une révision SVN. Je trouve que cela fonctionne mieux.

Answer 2

x.y.z.g

Les

incréments en g sont instables. (ou les RC) les incréments dans z sont des correctifs de bogues stables et moyens.
les incréments de y sont stables et signifient de nouvelles fonctionnalités.
les incréments en x sont stables, version majeure sans compatibilité ascendante à 100%.

Answer 3

J'ai déjà écrit un "Guide de style de versioning" élaboré. pour un grand projet de la mienne. Le projet n'a pas abouti, mais le guide de style est toujours disponible en ligne . C’est mon opinion personnelle. C’est peut-être utile (ou inspirant) pour vous.

Attention, il s’agit d’un texte long, qui passe du versioning des composants à la version des produits, etc. Il exprime également des opinions bien arrêtées sur certains schémas de version populaires de la communauté des logiciels libres, mais je les ai, alors 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 conserver une version publiée tout en poursuivant le développement dans TRUNK. Vous créerez donc une branche de maintenance et la gestion de votre numéro de révision se perdra.

Modifier: En tant que résumé, il établit une distinction entre les fichiers source de gestion des versions, les composants et le produit global. Il utilise un système de version x.y séparée pour les composants et le produit, avec une belle interdépendance entre les deux qui permet de tracer quelle version de composant appartient à quelle version de produit. Il explique également comment gérer les cycles alpha / bêta / release / patch sans endommager le système. En fait, il s’agit d’un modus operandi pour l’ensemble du cycle de développement, vous pouvez donc choisir de choisir. ; -)

Modifier 2: Comme suffisamment de personnes ont trouvé mon article utile pour en faire une "bonne réponse", j'ai recommencé à travailler sur cet article. Les versions PDF et LaTeX sont maintenant disponibles, une réécriture complète comprenant un meilleur langage et des graphiques explicatifs suivra dès que je peux trouver le temps. Merci pour vos votes!

Answer 4

Laissez-vous inspirer par Wikipedia: "Versioning logiciel"

Un autre " nouveau " et "relativement populaire" L’option est Versionnage sémantique

Résumé:

  

Étant donné le numéro de version MAJOR.MINOR.PATCH, incrémentez le:

     

  
1. Version MAJOR lorsque vous apportez des modifications incompatibles à l'API,
  
2. Version MINOR lorsque vous ajoutez des fonctionnalités de manière rétro-compatible, et
  
3. Version de PATCH lorsque vous corrigez des bogues compatibles avec les versions antérieures.
  

     

Des étiquettes supplémentaires pour les métadonnées de pré-publication et de génération sont disponibles en tant que   Extensions au format MAJOR.MINOR.PATCH.

Answer 5

a.b.c.d

Incréments: quand
 - d : corrections de bogues
 - c : maintenance, par exemple. amélioration de la performance
 - b : nouvelles fonctionnalités
 - a : changement d'architecture

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

Answer 6

Sur la base de mon expérience en matière de gestion des dépendances au niveau de plate-forme d'entreprise complexe et de gestion des versions, je recommande une approche que j'appelle le versioning semi-sémantique .

Fondamentalement, il repose sur la version sémantique 2.0 mais n'est pas aussi strict.

Segments de la version semi-sémantique:

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

Format de segment de libération principal:

  

MARKETTING.MAJOR.MINOR.PATCH

Chaque segment doit autoriser les caractères alphanumériques, mais des valeurs numériques pures sont recommandées pour les modifications incrémentielles logiques.

Comme SemVer, je recommande les composants majeurs, mineurs et de correctifs pour représenter les niveaux de compatibilité inversée, mais je recommande également de préfixer un composant Marketing . Cela permet aux propriétaires de produits, aux groupes de fonctionnalités et aux fonctionnalités, ainsi qu'aux préoccupations de l'entreprise de remplacer le composant principal indépendamment des problèmes de compatibilité technique.

Contrairement aux autres réponses, je ne recommande pas d’ajouter un numéro de build au segment principal. Ajoutez plutôt un segment postérieur à la publication après un '+' (ex: 1.1.0.0 + build.42). SemVer appelle cela les métadonnées de construction, mais je pense que le segment post-release est plus clair. Ce segment est idéal pour déclarer que les données de suffixe ne sont pas liées aux informations de compatibilité dans le segment de publication principal . Vous pouvez ensuite attribuer au numéro de version précédent un numéro incrémentiel qui se réinitialise après chaque version principale (par exemple, 1.1.0.0 - > 1.1.0.0 + build.1 - > 1.1.0.0 + build.2). - > 1.1.0.1). Certaines personnes préfèrent mettre le numéro de révision svn ici ou le git commit sha pour faciliter la liaison au référentiel de code. Une autre option consiste à utiliser le segment postérieur à la publication pour les correctifs logiciels et les correctifs, bien que cela puisse valoir la peine d’ajouter un nouveau composant de version principale à cette fin. Il peut toujours être supprimé lorsque le composant de correctif est incrémenté, car les versions sont effectivement alignées à gauche et triées.

Outre les segments de publication et post-publication, les utilisateurs souhaitent souvent utiliser un segment de pré-publication pour indiquer des pré-versions quasi stables, telles que alphas, bêta et candidats à la publication. L’approche de SemVer 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 supprimez le segment de version au même moment que vous ajoutez le segment post-publication, puis supprimez le segment de pré-version lors de la prochaine suppression du segment de version principal (par exemple: 1.0.1.2 - > 1.2.0.0-RC.1 - > 1.2.0.0). Des segments de pré-version sont ajoutés pour indiquer que la version est à venir, généralement un ensemble fixe de fonctionnalités pour des tests plus approfondis et un partage qui ne change pas de minute en minute en fonction du nombre de commits.

La beauté de tout cela sémantiquement défini de manière à couvrir presque tous les cas d'utilisation, c'est que vous pouvez les analyser, les trier, les comparer et les incrémenter de manière standard. Cela est particulièrement important. lors de l'utilisation de systèmes CI pour des applications complexes comportant de nombreux petits composants à version indépendante (tels que des micro-services), chacun avec ses propres dépendances gérées.

Si cela vous intéresse, j’ai écrit un analyseur semi-sémantique en ruby ??. Je devais non seulement utiliser ce modèle, mais également gérer d'autres applications qui l'utilisaient.

Answer 7

" Numéros de version " relèvent de votre système de contrôle de version interne. Les numéros de publication sont une question différente (et devraient être KEPT différentes).

S'en tenir à un système de publication MAJOR.MINOR simple (comme la v1.27), où MAJOR correspond au niveau de compatibilité (la version 2.x est incompatible ou très différente de la version 1.x) et MINOR correspond aux versions de votre correctif. ou améliorations mineures. Tant que vous suivez le format X.Y, vous pouvez également utiliser d'autres systèmes tels que YEAR.MONTH (2009.12) ou YEAR.RELEASE (2009.3). Mais vraiment, vous feriez mieux de vous en tenir à MAJOR.MINOR, à moins que vous n’ayez une bonne raison de ne pas le faire.

N'utilisez absolument rien qui ne corresponde pas au format XY car cela compliquerait la tâche des distros, sites d'annonces, etc., 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 comme se rapportant respectivement à MAJORS et à MINORS.

Et oui, 1.0 devrait être stable. Toutes les versions devraient être stables, sauf si elles sont marquées alpha, bêta ou RC. Utilisez Alphas pour les éléments connus et incomplets. Beta pour connu-cassé. RC pour "essayez-le; vous remarquerez probablement des choses que nous avons manquées ". Tout ce qui n'en a pas devrait (idéalement bien sûr) être testé, reconnu, avoir un manuel à jour, etc.

Answer 8

Il est plutôt courant de n'utiliser que le numéro de révision de Subversion.

Answer 9

Si c'est en SVN, 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 correspond au numéro de révision SVN.

Answer 10

Le versionnement dépend de vous. Je mettrais 1.0 sur la première version en laquelle j'avais confiance. Vous voudrez peut-être faire un suivi rapide avec d'autres versions, car certains éditeurs de logiciels ont donné une mauvaise réputation à 1.0.

Vous voulez un moyen de lier le numéro de version à la version exacte utilisée, mais vous voulez probablement que ce soit simple et agréable pour vos utilisateurs finaux. Pensez à utiliser des numéros de version standard et à marquer le référentiel SVN avec le numéro de version inclus.

Answer 11

Bien que le numéro de révision de Subversion soit simple et agréable, il supprime les informations du numéro de version. Les utilisateurs pourraient considérer cela comme une mauvaise chose.

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

Les numéros de version classiques ont tendance à "dramatiser". versions, de sorte que les utilisateurs peuvent créer une sorte d'attente. Il est plus facile de penser "j'ai la version 1.0, maintenant la version 1.1 ajoute ceci et cela, ça a l'air intéressant" que de penser "hier, nous avions lancé la révision SO 2587, aujourd’hui il est 3233, ça doit être beaucoup mieux!".

Bien sûr, cette dramatisation peut aussi être exagérée, les entreprises sélectionnant des numéros de version censés sembler plus intéressants que motivés par les différences réelles entre les produits. p>

Answer 12

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émente si vous avez un correctif. Remettre à zéro si majeur ++ ou mineur ++.
[marque]: a, b ou rc: a est une version alpha, b est une version bêta et rc est une version candidate. Notez que des versions telles que 1.3.57a, 1.3.57b ou 1.3.57rc sont antérieures à la version 1.3.57. Commencez à 0.0.0.

Answer 13

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

J'en ai eu marre de ça et j'ai convaincu tout le monde que le numéro de version majeure n'était que l'année et que la version mineure n'était qu'une version séquentielle au cours de l'année. Les utilisateurs ont semblé l’aimer et c’est une évidence de trouver le prochain numéro de version.

Year.Release.build

• année = année en cours
• release = sequence # de versions publiques avec nouvelle fonctionnalité - réinitialiser à 1 chaque année
• build = incrémenté pour le bogue corrections et versions internes

EDIT

** Il s’agit maintenant d’une application interne constamment améliorée **

Cela ne fonctionnerait probablement pas pour les applications commerciales où il est important de disposer de versions majeures à différentes périodes de l'année à des fins marketing et financières.

Answer 14

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

1. Choisissez un schéma de numérotation des révisions et respectez-le. Être cohérent.
2. Chaque changement de version doit représenter un changement significatif . La petite taille d'un changement est significative et les niveaux de changement reflétés dans le numéro de version sont à votre charge.

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

J'espère que cela vous aidera.

Answer 15

La raison de cette question est qu’il n’existe pas de moyen convenu de gérer les configurations.

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

Pour que cela se produise, vous aurez besoin de certains scripts de version au-dessus de SVN

Answer 16

Nous utilisons une syntaxe simple major.minor.julian_date.

Où;

• major - La première version est la 1, puis lorsque nous introduisons de nouvelles fonctionnalités ou des modifications tellement importantes qu’elles ne sont pas rétrocompatibles, augmentez ce nombre.
• mineur - Les versions majeures des jalons. Ce nombre augmente pour chaque build poussé par la production.
• julian_date - Julien Day , la construction a été poussée vers QA.

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

Ce n'est pas parfait, mais pratique car nous poussons les constructions vers l'assurance qualité presque quotidiennement.

Answer 17

Quelques bonnes informations ici:

Changement de version de fichier / Assemblée

Tout d'abord, les versions de fichier et d'assemblage ne doivent pas nécessairement coïncider. Je recommande que les versions de fichier changent à chaque construction. Toutefois, ne modifiez pas les versions des assemblages à chaque génération simplement pour pouvoir faire la différence entre deux versions du même fichier; utilisez la version du fichier pour cela. Pour décider quand modifier les versions d'assembly, il faut discuter des types de construction à prendre en compte: expédition et non expédition.

Versions non destinées à l'expédition En général, il est recommandé de garder les versions d'assemblage non-expédiées identiques entre les versions d'expédition. Cela évite les problèmes de chargement d'assemblages fortement nommés en raison de différences de version. Certaines personnes préfèrent utiliser la stratégie d'éditeur pour rediriger les nouvelles versions d'assembly pour chaque build. Je recommande toutefois de ne pas utiliser cette option pour les versions non destinées à l’expédition: elle n’évite pas tous les problèmes de chargement. Par exemple, si un partenaire copie votre application, il peut ne pas savoir installer la stratégie d'éditeur. Ensuite, votre application sera cassée pour eux, même si cela fonctionne très bien sur votre machine.

Toutefois, s'il existe des cas où différentes applications d'une même machine doivent se lier à différentes versions de votre assemblage, il est conseillé de leur attribuer différentes versions afin que la version correcte de chaque application puisse être utilisée sans devoir utiliser LoadFrom. / etc.

Versions d'expédition Quant à savoir si la modification de cette version pour les versions d’expédition est une bonne idée, cela dépend de la manière dont vous souhaitez que la liaison fonctionne pour les utilisateurs finaux. Souhaitez-vous que ces versions soient côte à côte ou en place? Y a-t-il beaucoup de changements entre les deux versions? Vont-ils casser des clients? Souhaitez-vous que cela les casse (ou voulez-vous forcer les utilisateurs à utiliser vos mises à jour importantes)? Si oui, vous devriez envisager d’incrémenter la version de l’assemblage. Mais, encore une fois, considérez que trop de fois peut entraîner des assemblages obsolètes sur le disque de l'utilisateur.

Lorsque vous modifiez vos versions d'assemblage Pour remplacer les versions codées en dur par la nouvelle, il est recommandé de définir une variable sur 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 lors de la génération pour mettre la version correcte. Je recommande de changer de version juste après l'expédition, pas juste avant, afin de laisser plus de temps pour détecter les bugs dus au changement.

Answer 18

Ou pour utiliser votre numéro de version 'pensé', numéro de subversion par virgule .. z.B.:

1.0.101 // révision 101, publication

ou 1.0.101-090303 // avec la date de sortie, j'utilise ce