Quel système de numérotation des versions recommandez-vous ?

Question

Ma question est la suivante : quel schéma de dénomination des versions doit être utilisé pour quel type de projet ?

Le plus courant est major.minor.fix, mais même cela peut conduire à 4 chiffres (par exemple Firefox 2.0.0.16). Certains ont un modèle selon lequel les nombres impairs indiquent les versions pour développeurs et les nombres pairs les versions stables. Et toutes sortes d'ajouts peuvent entrer dans le mélange, comme -dev3, -rc1, SP2, etc.

Existe-t-il des raisons de préférer un schéma plutôt qu'un autre et les différents types de projets (c'est-à-dire Open Source vs. Closed Source) devraient-ils avoir des schémas de dénomination de version différents ?

Answer 1

Il y a deux Il existe de bonnes réponses à ces questions (ainsi que de nombreuses préférences personnelles ; voir le commentaire de gizmo sur les guerres de religion).

Para public la norme Major.Minor.Revision.Build fonctionne le mieux IMO - les utilisateurs publics peuvent facilement savoir quelle version du programme ils ont et, dans une certaine mesure, à quel point leur version est dépassée.

Para dans la maison où les utilisateurs n'ont jamais demandé l'application, où le déploiement est géré par le service informatique et où les utilisateurs appellent le service d'assistance. Year.Month.Day.Build pour mieux fonctionner dans de nombreuses situations. Ce numéro de version peut donc être décodé pour fournir des informations plus utiles au service d'assistance que le numéro de version public.

Cependant, à la fin de la journée, je recommanderais avant tout - utiliser un système cohérent . S'il existe un système que vous pouvez configurer/script votre compilateur pour qu'il l'utilise automatiquement à chaque fois, utiliser cette .

La pire chose qui puisse arriver est de publier des binaires avec le même numéro de version que les précédents - j'ai récemment traité des rapports d'erreurs réseau automatisés (application de quelqu'un d'autre), et j'en suis venu à la conclusion que les numéros de version Year.Month.Day.Build indiqués dans les core dumps n'étaient pas du tout à jour avec l'application elle-même (l'application elle-même utilisait un écran d'accueil avec les vrais numéros - qui bien sûr n'étaient pas tirés du binaire comme on pourrait le supposer). Le résultat est que je n'ai aucun moyen de savoir si les crash dumps proviennent d'un binaire vieux de 2 ans (ce que le numéro de version indique) ou d'un binaire vieux de 2 mois, et donc aucun moyen d'obtenir le bon code source (pas de contrôle de source non plus !).

Answer 2

Je suis un grand fan de Versionnement sémantique

Comme beaucoup d'autres l'ont fait remarquer, il utilise le format X.Y.Z et donne de bonnes raisons de le faire.

Answer 3

Voici ce que nous utilisons dans notre entreprise : Principale . Mineur . Version du correctif . Numéro de construction .

En Principale Le changement implique un cycle de publication complet, y compris l'implication du marketing, etc. Ce nombre est contrôlé par des forces extérieures à la R&D (par exemple, dans l'un des endroits où j'ai travaillé, le service marketing a décidé que notre prochaine version serait "11" - pour faire jeu égal avec un concurrent. Nous en étions alors à la version 2 :)).

Mineur est modifié lorsqu'une nouvelle fonctionnalité ou un changement de comportement majeur est ajouté au produit.

Version du correctif augmente d'une unité chaque fois qu'un correctif est officiellement ajouté à la version, qui ne comprend généralement que des corrections de bogues.

Version de construction est utilisé lorsqu'une version spéciale est publiée pour un client, généralement avec une correction de bogue qui lui est spécifique. En général, cette correction sera intégrée au prochain correctif ou à la prochaine version mineure (et la gestion des produits marque généralement le bogue comme "sera publié pour le correctif 3" dans notre système de suivi).

Answer 4

Notre département R&D utilise 1.0.0.0.0.000 : MAJOR.minor.patch.audience.critical_situation.build

S'il vous plaît, s'il vous plaît ne le faites pas.

Answer 5

Ce type de question relève plus de la guerre de religion que d'aspects objectifs. Il y a toujours des tonnes de pour et de contre contre un système de numérotation ou un autre. Tout ce que les gens pourraient (ou devraient) vous donner, c'est le système qu'ils ont utilisé et pourquoi ils l'ont choisi.

De mon côté, j'utilise un schéma X.Y.Z. Tous les numéros sont des numéros où :

• X indiquer une modification de l'API publique qui introduit une incompatibilité ascendante
• Y indiquent l'ajout de certaines caractéristiques
• Z indiquer une correction (soit la correction d'un bogue, soit la modification de la structure interne sans impact sur la fonctionnalité)

Eventuellement, j'utilise le suffixe "Beta N" si je veux avoir un retour des utilisateurs avant la sortie officielle. Pas de suffixe "RC" car personne n'est parfait et il y aura toujours des bugs ;-)