Bump version avant de lancer un nouveau développement ou lors du balisage d'une version, quel est le meilleur?

Certains projets bumpent la version avant de lancer un nouveau développement, tandis que les autres projets bumpent la version lors du balisage d'une version.

Quelle approche est la meilleure?

Si le numéro de version n'a pas changé au début de la nouvelle phase, les développeurs peuvent oublier de le changer et simplement libérer le programme.

Si le numéro de version a changé avant la publication du balisage, 2 les numéros de version (balise et Makefile / AssemblyInfo.cs) ne correspondent pas.

git describe peut vous donner la v1.2.3.4-15-g1234567 si la révision actuelle est postérieure à la v1.2.3.4, mais vous avez déjà modifié les fichiers pour avoir la v1.2.3.5

La principale raison du numéro de version est que, lorsqu'un bug est découvert, vous pouvez déboguer en utilisant la version réelle du code source dans laquelle l'erreur s'est réellement produite (découvrez ainsi la vraie raison du bug).

Peu importe le schéma de version que vous utilisez tant que l'utilisateur de votre produit peut communiquer au développeur suffisamment d'informations pour que le développeur puisse atteindre cet objectif.

Les autres raisons du contrôle de version sont les équipes marketing et d'aide (parfois légales).
Ces équipes ont leurs propres priorités pour le contrôle de version.

• Aide
  Veut un moyen facile de déterminer la compatibilité et les fonctionnalités et potentiellement la stabilité (voir schéma de nombres pairs / pairs Linux).
• Marketing
  veut un plus grand nombre à chaque fois (de préférence au-dessus de 2)
• Legal
  souhaite s'assurer que toutes les fonctionnalités sont engagées avant d'augmenter le nombre.

Dans tous les cas, le schéma utilisé est sans importance. Tant que vous êtes cohérent (ou disposez d'une documentation très détaillée et facilement disponible sur les changements de signification).

Lorsque vous utilisez des numéros de version à quatre segments comme les assemblages .NET, je préfère utiliser une balise de contrôle de version pour définir les trois premiers segments, puis le quatrième segment est le nombre de validations depuis cette balise.

Par exemple, une version est étiquetée "v1.2.3". Sigit-describe renvoie "v1.2.3-4-g1a2b3c4", alors une fois construit, cet assemblage est versionné en 1.2.3.4.

Si une balise est appliquée ultérieurement à cette version, git-describe retournera "v1.2.4" à la place, ce qui représente la version 1.2.4.0. Le prochain commit serait alors 1.2.4.1.

Les avantages que je trouve de ce système sont:

• Chaque commit incrémente automatiquement le numéro de version.
• Une version peut devenir une version ".0" en la marquant simplement.
• Bien qu'il ne soit pas parfait, ce système fonctionne avec DVCS car il compte le nombre de validations depuis la balise la plus récente.