Quand changez-vous le numéro de version majeur / mineur / correctif?

Dupliquer possible:
Quelle «convention de dénomination de version» utilisez-vous?

Changez-vous les numéros de version majeur / mineur / correctif juste avant de publier ou juste après?

Exemple: Vous venez de publier 1.0.0 au monde entier (huzzah!). Mais attendez, ne célébrez pas trop. 1.1.0 sort dans six semaines! Donc, vous corrigez un bogue et faites une nouvelle construction. Comment s'appelle cette version? 1.1.0.0 ou 1.0.0.xxxy (où xxxy est le numéro de version de 1.0.0 incrémenté)?

Gardez à l'esprit que vous pouvez avoir 100 fonctionnalités et bugs pour aller dans 1.1.0. Donc, il serait peut-être bien de l'appeler 1.0.0.xxxy, car vous n'êtes nulle part proche de 1.1.0. Mais d’autre part, un autre développeur peut travailler sur la version 2.0.0, auquel cas votre construction pourrait être mieux nommée 1.1.0.0 et sa version 2.0.0.0 au lieu de 1.0.0.xxxy et 1.0.0.xxxz, respectivement.

Après avoir publié votre logiciel, le numéro de version doit être incrémenté immédiatement.

Pourquoi?

Supposons que vous suivez un schéma tel que le contrôle de version sémantique et que vous avez un numéro de build dans la version. Donc, vous pourriez avoir [Major]. [Minor]. [Patch]. [Build]. Je vais appeler la partie [Major]. [Minor]. [Patch].

Vous allez créer plusieurs versions au cours du développement. Chaque version est un instantané de développement de votre prochaine version. Il est logique d'utiliser la même version pour vos versions de développement et de version. La version indique quelle version vous travaillez vers .

Si vous vous préparez à la publication et que le logiciel passe tous ses tests, vous ne voudrez pas le reconstruire et le retester simplement parce que vous deviez mettre à jour la version. Lorsque vous publiez finalement une version, vous indiquez que "build 1.1.0.23" sera dorénavant appelé "version 1.1.0".

Le modèle incrémentation après libération est également utile pour la création de branches. Supposons que vous ayez une branche de développement principale et que vous créiez des branches de maintenance pour les versions. Au moment où vous créez votre branche de publication, votre branche de développement n'est plus liée au numéro de version de cette version. La branche de développement contient du code qui fait partie de la prochaine version, donc la version devrait en tenir compte.

J'essaie généralement d'utiliser SemVer pour les numéros de version internes. C'est bien de pouvoir savoir quelque chose à propos d'une version basée sur la sémantique de son numéro de version.

Pendant le développement, j'essaie de changer les numéros de version immédiatement (si possible) . Parfois, il est difficile de savoir si le changement sera un changement radical ou non (ce qui influencera mon numéro de version), aussi rien n'est «figé dans la pierre».

Pour aborder votre exemple spécifique:

• Au cours du développement, les versions préliminaires seraient 1.0.1-alpha.1, 1.0.1-alpha.2, etc.
• La version finale du correctif serait la version 1.0.1.

Cela dit, les numéros de version des produits «destinés au public» sont souvent définis par le marketing et sont complètement différents. C'est hors de mon contrôle, donc inutile de vous en inquiéter.

Supposons ABCD dans les réponses. Quand augmentez-vous chacun des composants?

Cela dépend essentiellement de la politique de votre entreprise. Notre politique d'entreprise est la suivante:

• A - Modifications importantes (> 25%) ou ajouts de fonctionnalités ou d'interface.
• B - petits changements ou ajouts de fonctionnalités ou d'interface.
• C - changements mineurs qui cassent l'interface.
• D - Corrige une construction qui ne change pas l'interface.

Dans les projets / organisations plus importants, les numéros de version majeurs et mineurs sont contrôlés par les services marketing et sont généralement incrémentés pour des raisons marketing. Dans mon organisation, les groupes visent à publier une version majeure et une version mineure chaque année. On s'attend à ce que les versions majeures contiennent de nouvelles fonctionnalités importantes et qu'il existe une compatibilité binaire entre les API pour toutes les versions portant le même numéro de version majeure. Toutefois, le marketing peut choisir de déclasser une modification de version majeure en modification mineure, car les fonctionnalités promises ne sont pas fournies, ou inversement, par exemple, pour éviter la concurrence effrénée.

Les nombres de construction majeurs et mineurs (c et d dans abcd) sont généralement contrôlés par le développement. c est le numéro de build et d est utilisé pour les correctifs sur une version ou une version particulière de c.

Dans votre cas, lorsque vous modifiez les numéros de version majeur et mineur est moins pertinent que de garantir l'exactitude des numéros de version majeure et mineure. Dans mon entreprise, nous modifions les numéros de build majeurs et mineurs dans le cadre du processus de création de branches dans le contrôle de source. La branche principale contient généralement la dernière version, mais le marketing n’a peut-être pas encore décidé du numéro de version de la version.

Nous essayons de suivre l' exemple Eclipse . Il fait un meilleur travail d’explication que je ne le peux, mais pour nous, il fonctionne comme suit:

Lorsque vous publiez la version 1.0.0.0, le numéro de version que vous modifiez dépend du type de modification que vous apportez.

• Une version qui n'affecte pas l'API, envisagez un correctif de bogue permettant à l'API actuelle de fonctionner de la manière attendue, est disponible à la version 1.0.1
• Une version qui ajoute à l'API mais ne modifie pas l'API existante, vous avez peut-être ajouté une nouvelle fonctionnalité qui ne rend pas les clients actuels incomparables avec la nouvelle version. Cela peut également inclure un nombre quelconque de corrections ci-dessus.
• Une version rompt l'API actuelle en supprimant quelque chose, en modifiant quelque chose qui empêche la comparabilité avec les clients actuels. Cela peut également avoir un nombre quelconque des correctifs ci-dessus.

En ce qui concerne l'utilisation de la 4ème section du numéro de version, nous l'utilisons pour différencier les différentes versions de Nuget (la solution de gestion de packages que nous utilisons pour .net). Cela nous évite d'avoir à vider les caches chaque fois que nous devons mettre à jour notre logiciel non publié.

Il n'y a pas de prochaine construction. Sur cette branche.

Version idéalisée de notre schéma.

PRETTY_BRANCH_NAME-build est identifié sur toutes les branches et PRETTY_BRANCH_NAME est fixé à la création de la branche.

Notre schéma de branchement (*) est le suivant:

Les branches de niveau supérieur, PRETTY_BRANCH_NAME de chacune d’elles est un nom de code, parler du numéro de version à ce niveau n’a pas de sens, il peut y avoir un schéma planifié, mais il changera avant la publication.

• une branche de TNG ( la prochaine génération ) où se développe à long terme. Souvent, nous ne l’avons même pas et il n’a jamais (libéré) de sous-branches.

• une branche TCG ( la génération actuelle ) où le développement actuel est fait. PRETTY_BRANCH_NAME est un nom de code.

• une branche TPG ( la génération précédente ). Souvent, plus de développement n’est fait ici, mais il peut y avoir une activité dans les sous-branches.

Une sous-branche est constituée d'une branche de niveau supérieur (de TCG, en présence d'une migration lente de TPG) lors du démarrage d'une version bêta pour une version majeure. PRETTY_BRANCH_NAME est quelque chose comme "1.3.X" (X est la lettre, pas le chiffre, cela signifie que nous avons l'intention de fournir des versions 1.3 à partir d'ici). la branche TCG.

Idéalement, la publication devrait être instantanée sur cette branche, mais nous savons que nous ne sommes pas parfaits et que nous devons souvent effectuer des modifications de dernière minute tout en permettant aux autres utilisateurs de continuer à travailler pour la prochaine publication mineure. Ainsi, des sous-sous-branches sont créées pour la stabilisation finale, avec de jolis noms représentant le numéro de version officiel (à ce moment-là, même le marketing ne voudra pas le changer), comme "1.3", "1.3.1" dans la branche "1.3.X", la dernière version de chacun est la version.

Si nous avions eu un quatrième niveau, les noms des sous-sous-branches auraient été "1.3.0.X" et nous aurions eu des sous-3 branches "1.3.0.0" "1.3.0.1".

(*) Au niveau de la version. Il peut y avoir des sous-branches de projet sur chacune d’elles.

Si vous vendez un logiciel, vous obtiendrez une nouvelle version majeure à chaque fois que les ventes / le marketing doivent gagner un bonus plus important :-).

Si vous avez un peu de contrôle alors:

1. Rejets majeurs quand:

   • Il existe certaines incompatibilités avec la version précédente nécessitant une conversion, comme de Python 2 à Python 3.

   • Il y a tout un tas de nouvelles fonctionnalités.

2. Versions mineures pour toute modification mineure de la fonctionnalité.

3. Version de correctif pour les corrections de bugs.