Obtenir les bons numéros de version du logiciel. v1.0.0.1 [fermé]

StackOverflow https://stackoverflow.com/questions/134517

Question

Je distribue des logiciels en ligne et je me demande toujours s'il existe un moyen approprié de mieux définir les numéros de version.

Supposons A.B.C.D dans les réponses. Quand augmentez-vous chacun des composants?

Utilisez-vous d'autres astuces portant le numéro de version, telles que D mod 2 == 1 signifie qu'il s'agit d'une version interne uniquement?

Avez-vous des versions bêta avec leurs propres numéros de version ou avez-vous des versions bêta par numéro de version?

Était-ce utile?

La solution

Je commence à aimer la convention Year.Release [.Build] que certaines applications (par exemple, Perforce) utilisent. En gros, cela indique simplement l'année dans laquelle vous publiez et la séquence de cette année. Donc 2008.1 serait la première version, et si vous en publiiez un ou trois ou trois mois plus tard, elle passerait à 2008.2.

L'avantage de ce schéma est qu'il n'y a aucune implication & "; magnitude &"; de la version, où vous obtenez des arguments sur la question de savoir si une fonctionnalité est suffisamment importante pour justifier un incrément de version majeur.

Un élément facultatif consiste à baliser le numéro de version, mais cela a tendance à être uniquement à des fins internes (par exemple, ajouté à l'EXE / DLL afin que vous puissiez inspecter le fichier et vous assurer que la bonne version est présente).

Autres conseils

À mon avis, presque tous les systèmes de numéros de version peuvent fonctionner de manière plus ou moins saine. Le système sur lequel je travaille utilise des numéros de version tels que 11.50.UC3, où U indique Unix 32 bits et C3 est un numéro de révision mineure (groupe de correctifs); d'autres lettres sont utilisées pour d'autres types de plateformes. (Je ne recommanderais pas ce schéma, mais cela fonctionne.)

Il y a quelques règles d'or qui n'ont pas encore été énoncées, mais qui sont implicites dans ce que les gens ont discuté.

  • Ne publiez pas la même version deux fois. Une fois que la version 1.0.0 a été publiée, elle ne peut plus être publiée.
  • Le nombre de versions devrait augmenter de façon monotone. Autrement dit, le code de la version 1.0.1 ou 1.1.0 ou 2.0.0 doit toujours être ultérieur à la version 1.0.0, 1.0.9 ou 1.4.3 (respectivement).

Maintenant, dans la pratique, les utilisateurs doivent publier des correctifs pour les anciennes versions alors que des versions plus récentes sont disponibles - voir GCC, par exemple:

  • GCC 3.4.6 a été publié après les versions 4.0.0, 4.1.0 (et AFAICR 4.2.0), mais il conserve les fonctionnalités de GCC 3.4.x au lieu d’ajouter les fonctionnalités supplémentaires ajoutées à GCC 4.x.

Vous devez donc construire votre schéma de numérotation des versions avec soin.

Un autre point en lequel je crois fermement:

  • Le numéro de version de la version n’est pas lié à la numérotation de version du système CM (VCS), à l’exception des programmes triviaux. Tout logiciel sérieux contenant plus d’un fichier source principal aura un numéro de version non lié à la version d’un fichier.

Avec SVN, vous pouvez utiliser le numéro de version de SVN, mais probablement pas, car il change trop imprévisiblement.

Pour les éléments avec lesquels je travaille, le numéro de version est une décision purement politique.

Incidemment, je connais des logiciels qui ont traversé des versions de la version 1.00 à la version 9.53, mais qui ont ensuite été modifiés en 2.80. C'était une grave erreur dictée par le marketing. Certes, la version 4.x du logiciel est / était obsolète, elle n’a donc pas immédiatement donné lieu à confusion, mais la version 5.x du logiciel est toujours utilisée et vendue et les révisions ont déjà atteint la version 3.50. Je suis très inquiet de ce que mon code, qui doit fonctionner à la fois avec les versions 5.x (ancien style) et 5.x (nouveau style), le fera lorsque le conflit inévitable se produira. J'imagine que je dois espérer qu'ils changeront peu à peu pour passer à la version 5.x jusqu'à ce que l'ancienne version 5.x soit vraiment morte - mais je ne suis pas optimiste. J'utilise également un numéro de version artificiel, tel que 9.60, pour représenter le code 3.50, afin de pouvoir effectuer des tests if VERSION > 900 rationnels, sans avoir à effectuer: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), où je représente la version 9.00 par 900. Et puis, il y a la modification importante introduite dans la version 3.00.xC3 - mon système ne parvient pas à détecter les modifications au niveau de la version mineure ... grommel ... grommel ...

NB : Eric Raymond fournit des HOWTO Practice pour les versions de logiciel , y compris la section (liée) sur les versions de dénomination (numérotation).

J'utilise habituellement D comme compteur de construction (incrémentation automatique par compilateur) J'incrémente C chaque fois qu'une version est publiée sur & "Public &"; (toutes les versions ne sont pas publiées) A et B sont utilisés comme numéro de version majeur / mineur et modifiés manuellement.

Je pense qu'il y a deux façons de répondre à cette question et elles ne sont pas entièrement complémentaires.

  1. Technique: incrémenter des versions en fonction de tâches techniques. Exemple: D est le numéro de construction, C est la version itérative, B est une version mineure, A est une version majeure. Définir les versions mineures et majeures est vraiment subjectif, mais pourrait être lié à des choses telles que des modifications de l’architecture sous-jacente.
  2. Marketing: incrémentez les versions en fonction du nombre de " nouveaux " ou " utile " des fonctionnalités sont fournies à vos clients. Vous pouvez également associer les numéros de version à une stratégie de mise à jour ... Les modifications apportées à A obligent l'utilisateur à acheter une licence de mise à niveau, contrairement aux autres modifications.

Je pense que le résultat final consiste à trouver un modèle qui fonctionne pour vous et vos clients. J'ai vu des cas où les versions paires sont des versions publiques, et les versions impaires sont considérées comme des versions bêta ou dev. J'ai déjà vu des produits ignorer C et D tous ensemble.

Ensuite, citons l'exemple de Micrsoft, dans lequel la seule explication rationnelle des numéros de version du .NET Framework est que Marketing était impliqué.

Notre politique:

  • A - Changements importants (> 25%) ou ajouts de fonctionnalités ou interface.
  • B - petits changements ou ajouts de fonctionnalités ou interface.
  • C - modifications mineures qui casser l'interface.
  • D - corrige un construire qui ne change pas le interface.

Les gens ont tendance à vouloir rendre les choses plus difficiles que nécessaire. Si votre produit ne possède qu'une seule branche de longue durée, il suffit de nommer les versions successives par leur numéro de version. Si vous avez une sorte de & Quot; corrections de bugs mineurs sont gratuites, mais vous devez payer pour les nouvelles versions majeures & Quot ;, puis utilisez 1.0, 1.1 ... 1.n, 2.0, 2.1. .. etc.

Si vous ne savez pas immédiatement quels sont les symboles A, B, C et D dans votre exemple, vous n'en avez évidemment pas besoin.

La seule utilisation du numéro de version que j'ai eue a été de permettre à un client de me dire qu'il utilise la version 2.5.1.0 ou autre.

Ma seule règle est conçue pour minimiser les erreurs en signalant ce nombre: les quatre chiffres doivent comporter un seul chiffre . 

1.1.2.3

est ok, mais 

1.0.1.23

n'est pas. Les clients sont susceptibles de signaler les deux chiffres (verbalement, au moins) comme suit: & "Un-un-deux-trois &";.

L'incrémentation automatique des numéros de build entraîne souvent des numéros de version tels que 

1.0.1.12537

ce qui n'aide pas vraiment non plus.

Un bon schéma non technique utilise simplement la date de compilation dans ce format:

YYYY.MM.DD.BuildNumber

Où BuildNumber est un nombre continu (liste de modifications) ou recommence à 1 à chaque jour.

Exemples: 2008.03.24.1 ou 2008.03.24.14503

Il s’agit principalement de versions internes, les versions publiques verraient la version imprimée 2008.03 si vous ne publiez pas plus d’une fois par mois. Les versions de maintenance sont marquées 2008.03a, 2008.03b, etc. Ils devraient rarement dépasser & Quot; c & Quot; mais si c'est le cas, c'est un bon indicateur dont vous avez besoin de meilleures procédures d'assurance de la qualité et / ou de test.

Les champs de version couramment vus par l'utilisateur doivent être imprimés de manière conviviale " Mars 2008 " format, réservez les informations plus techniques dans la boîte de dialogue À propos de ou dans les fichiers journaux.

Plus gros désavantage: la compilation du même code un autre jour peut changer le numéro de version. Mais vous pouvez éviter cela en utilisant la liste de modifications du contrôle de version comme dernier numéro et en vérifiant si cela permet de déterminer si la date doit également être modifiée.

J'utilise V.R.M par ex. 2.5.1

Les modifications de V (version) sont une réécriture majeure
Les modifications de R (révision) sont des nouvelles fonctionnalités ou des corrections de bogues
Les modifications (modifications) sont des corrections mineures de bux (fautes de frappe, etc.)

J'utilise parfois un numéro de validation SVN à la fin.

Tout est vraiment subjectif à la fin de la journée et à vous de décider vous-même / votre équipe.

Il suffit de jeter un coup d’œil sur toutes les réponses - toutes très différentes.

Personnellement, j'utilise Major.Minor.*.* - Où Visual Studio entre automatiquement le numéro de révision / génération. Ceci est utilisé là où je travaille aussi.

Cette note technique Apple décrit un bon schéma de gestion des versions convivial basé sur l'ancien Mac OS: http://developer.apple.com/technotes/tn/tn1132.html

J'aime Year.Month.Day. Ainsi, la version 2009.6.8 serait la & version; & "; de ce post. Il est impossible de dupliquer (raisonnablement) et c'est très clair quand une version est plus récente. Vous pouvez également supprimer les décimales et le rendre v20090608.

Dans le cas d'une bibliothèque, le numéro de version vous indique le niveau de compatibilité entre deux versions et donc la difficulté d'une mise à niveau.

Une version de correctif de bogue doit préserver la compatibilité binaire, source et de sérialisation.

Les versions mineures signifient différentes choses pour différents projets, mais elles n'ont généralement pas besoin de préserver la compatibilité de la source.

Les numéros de version majeurs peuvent rompre les trois formes.

J'ai écrit davantage sur la justification ici .

Dans le monde des githubs, il est devenu courant de suivre > Semver & "; spec pour les numéros de version.

De http://semver.org/ :

  

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

     

Version MAJOR lorsque vous apportez des modifications incompatibles à l'API, version MINOR   lorsque vous ajoutez des fonctionnalités de manière rétro-compatible, et PATCH   version lorsque vous apportez des corrections de bogues compatibles en amont. Additionnel   les étiquettes pour les métadonnées de pré-publication et de création sont disponibles en tant qu'extensions   au format MAJOR.MINOR.PATCH.

Pour le développement interne, nous utilisons le format suivant. 

[Program #] . [Year] . [Month] . [Release # of this app within the month]

Par exemple, si je publie l'application n ° 15 aujourd'hui et qu'il s'agit de la troisième mise à jour de ce mois-ci, mon numéro de version sera

. 
15.2008.9.3

C'est totalement non standard, mais c'est utile pour nous.

Pour les six dernières versions majeures, nous avons utilisé M.0.m.b, où M est la version majeure, m la version mineure et b le numéro de build. Les versions publiées incluent donc 6.0.2, 7.0.1, ... et 11.0.0. Ne demandez pas pourquoi le deuxième nombre est toujours 0; Je l'ai demandé à plusieurs reprises et personne ne le sait vraiment. Nous n’avons pas reçu de non-zéro là-bas depuis la publication de la version 5.5 en 1996.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top