Demandez à 5 développeurs et vous obtiendrez probablement 6 suggestions différentes pour la numérotation des versions.
Quel que soit le système de numéro de version que vous choisissez, vous devez vous assurer qu'il suit certaines directives. La plupart des systèmes de gestion de paquets aiment pouvoir déterminer quelle est la dernière version, donc vous devriez vous assurer que votre système de numéro de version augmente toujours, avec le premier numéro ayant la plus haute priorité, le second le deuxième plus haut, etc. Vous êtes sur la version 3 maintenant, vous ne devriez pas régresser pour libérer 1.4 si vous décidez d'aller avec un système XY, vous devriez au moins commencer sur 3.1 ou 4.0. La plupart des systèmes de gestion de paquets ont un concept d'époque pour réparer des cas comme celui-ci dans lequel un numéro de version régresse, mais vous ne devriez pas vous fier à cela.
En général, votre numéro de version devrait être composé de nombres pointés, chacun croissant dans l'ordre numérique (donc, 1, 2, 3, ..., 9, 10, 11 ..., pas d'ordre lexicographique qui serait trié 1, 10, 11, 2, 3, ...). Certaines personnes aiment utiliser un système major.minor.patch, dans lequel le nombre principal augmente pour les modifications incompatibles vers l'arrière ou les nouvelles fonctionnalités majeures, les incréments de nombre mineur pour les modifications rétrocompatibles ou les nouvelles fonctionnalités mineures, ainsi que les changements de patch uniquement pour les corrections de bogues rétrocompatibles qui n'introduisent aucune nouvelle fonctionnalité.
D'autres aiment utiliser un système comme Ubuntu, avec year.month ou year.release (éventuellement avec un troisième nombre également pour les correctifs ou les corrections de bugs, ou year.month.day). Cela peut aider à éviter de devoir décider ce qui constitue une caractéristique «majeure» et peut donner aux gens un nombre un peu plus mémorable qu'un «7» ou un «23» arbitraire. Cela a l'inconvénient de ne pas avertir vos utilisateurs lorsque vous effectuez des modifications incompatibles avec les versions antérieures, même si cela dépend de ce que vous faites, si vous maintenez toujours la compatibilité ascendante ou si vous numérotez quelque chose comme Linux. une distribution qui contient tant de parties, dont certaines peuvent être rétrocompatibles et d'autres pas, ce qui garantit une rétrocompatibilité entre les versions n'a pas vraiment de sens).
Si vous pensez que vous pouvez vous engager à une notion forte de rétrocompatibilité, je vous recommande d'utiliser un système major.minor.patch en suivant les instructions données dans Semantic Versioning. Dans ces instructions, vous incrémentez la version majeure pour les modifications incompatibles avec les versions antérieures. Vous incrémentez la version mineure pour les modifications rétrocompatibles qui peuvent encore ajouter de nouvelles fonctionnalités (donc quelqu'un peut dépendre de la version supérieure à 2.3.0, car c'est la version qu'une nouvelle fonctionnalité a été ajoutée, mais moins de 3.0.0, car cela peut avoir changements incompatibles). Vous incrémentez ce niveau de correctif uniquement pour les corrections de bugs. Si vous êtes sur la version 3 en ce moment, je commencerais votre prochaine version à 4.0.0, puis je suivrais ce modèle à partir de maintenant.
Si vous n'avez pas envie de faire le travail pour assurer la compatibilité et déterminer ce qui est et n'est pas rétrocompatible, alors rendez-vous simplement avec year.month, year.month.version ou year.version, où la version est incrémentée de 1 pour chaque version de ce mois ou de cette année (en fonction de la fréquence de vos versions). Votre prochaine version serait donc quelque chose comme 2010.1, 2010.8.1, ou 2010.8, selon le formulaire exact (ou vous pourriez simplement aller avec 10.1, 10.8.1, etc).
(Hmm. Je suis juste un développeur, et je pense que je vous ai donné au moins 6 choix maintenant. Eh bien, espérons que l'un d'entre eux travaille pour vous)
je vais marquer les meilleurs conseils (pour moi) comme réponse. – jorgebg
@jorgebg en disant cela, vous avez marqué automatiquement cette question –
Vous avez raison. J'ai changé la question en communauté wiki – jorgebg