Que représentent généralement les nombres dans une version (c.-à-d. V1.9.0.1)?

C'est peut-être une question idiote, mais j'ai toujours supposé que chaque nombre délimité par une période représentait un seul composant du logiciel. Si c'est vrai, représentent-ils jamais quelque chose de différent? Je voudrais commencer à attribuer des versions aux différentes versions de mon logiciel, mais je ne sais pas vraiment comment il devrait être structuré. Mon logiciel comporte cinq composants distincts.

Dans la version 1.9.0.1 :

• 1 : révision majeure (nouvelle interface utilisateur, beaucoup de nouvelles fonctionnalités, changement conceptuel, etc.)

• 9 : révision mineure (peut-être un changement dans un champ de recherche, 1 fonctionnalité ajoutée, collection de corrections de bogues)

• 0 : version de correction de bogue

• 1 : Numéro de build (si utilisé) - c'est pourquoi vous voyez le framework .NET utiliser quelque chose comme 2.0.4.2709

Vous ne trouverez pas beaucoup d'applications descendant à quatre niveaux, 3 est généralement suffisant.

Il existe la spécification de version sémantique

Voici le résumé de la version 2.0.0:

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

1. Version MAJEURE lorsque vous apportez des modifications d'API incompatibles,
2. Version MINEURE lorsque vous ajoutez des fonctionnalités de manière rétrocompatible, et
3. Version PATCH lorsque vous effectuez des corrections de bogues rétrocompatibles.

Des étiquettes supplémentaires pour les métadonnées de pré-version et de build sont disponibles sous forme d'extensions au format MAJOR.MINOR.PATCH.

Cela peut être très arbitraire et diffère d'un produit à l'autre. Par exemple, avec la distribution Ubuntu, 8.04 fait référence à 2008.

En règle générale, les nombres les plus à gauche (majeurs) indiquent une version majeure, et plus vous allez vers la droite, plus le changement impliqué est petit.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Plus il y a de points, plus la sortie est mineure. Il n'y a pas de norme solide au-delà de cela - peut signifier différentes choses en fonction de ce que les responsables du projet décident.

WordPress, par exemple, suit ces lignes:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 à 2.0 serait une grosse version - fonctionnalités, changements d'interface, changements majeurs aux API, rupture de certains modèles et plugins 1.6, etc. 2.0 à 2.0.1 serait une version mineure - peut-être corrigeant un bogue de sécurité. 2.0.2 à 2.1 serait une version importante - de nouvelles fonctionnalités, en général.

Les nombres peuvent être utiles comme décrit par d'autres réponses, mais considérez comment ils peuvent aussi être assez dénués de sens ... Sun, vous connaissez SUN, java: 1.2, 1.3, 1.4 1.5 ou 5 puis 6. Dans les bons vieux numéros de version d'Apple II Meant Quelque chose. De nos jours, les gens abandonnent les numéros de version et optent pour des noms idiots comme "Feisty fig" (ou quelque chose comme ça) et "hardy heron" et "europa" et "ganymede". Bien sûr, c'est beaucoup moins utile car vous allez manquer de lunes de Jupiter avant d'arrêter de changer le programme, et comme il n'y a pas d'ordre évident, vous ne pouvez pas dire lequel est le plus récent.

Dans la version v1.9.0.1: il s'agit du schéma de version explicite utilisé lorsque vous ne souhaitez pas utiliser de nom pour les pré-versions ou construire comme -alpha, -beta.

1: version majeure qui pourrait casser la compatibilité descendante

9: Ajout de nouvelles fonctionnalités pour prendre en charge votre application avec compatibilité descendante avec la version précédente.

0: quelques corrections de bugs mineurs

1: numéro de build (numéro de pré-version)

mais de nos jours, vous ne trouverez pas un tel schéma de version. Référez-vous à Semantic Versionsing [semver2.0] https://semver.org/

Les numéros de version ne représentent généralement pas des composants séparés. Pour certaines personnes / logiciels, les chiffres sont assez arbitraires. Pour d'autres, différentes parties de la chaîne de numéro de version représentent des choses différentes. Par exemple, certains systèmes augmentent des parties du numéro de version lorsqu'un format de fichier change. Donc, V 1.2.1 est un format de fichier compatible avec toutes les autres versions de V 1.2 (1.2.2, 1.2.3, etc.) mais pas avec V 1.3. En fin de compte, c'est à vous de décider quel schéma vous souhaitez utiliser.

Habituellement, c'est:

MajorVersion.MinorVersion.Revision.Build

Cela dépend, mais la représentation typique est celle de major.minor.release.build .

Où:

• Majeur est la version majeure de votre logiciel, pensez .NET 3.x
• minor est la version mineure de votre logiciel, pensez .NET x.5
• release est la version de cette version, généralement les corrections de bogues incrémenteront cette
• build est un nombre qui indique le nombre de builds que vous avez effectués.

Ainsi, par exemple, 1.9.0.1, signifie qu'il s'agit de la version 1.9 de votre logiciel, après 1.8 et 1.7, etc. où 1.7, 1.8 et 1.9 ajoutent généralement de petites quantités de nouvelles fonctionnalités aux côtés de corrections de bogues. Puisqu'il s'agit de xx0.x, c'est la version initiale de 1.9, et c'est la première version de cette version.

Vous pouvez également trouver de bonnes informations sur l'article de Wikipédia sur le sujet .

Major.Minor.Bugs

(Ou une variation à ce sujet)

Les bogues sont généralement des corrections de bogues sans nouvelle fonctionnalité.

Mineur est un changement qui ajoute de nouvelles fonctionnalités mais ne change pas le programme de manière majeure.

Majeur est un changement dans le programme qui brise les anciennes fonctionnalités ou est si important qu'il change en quelque sorte la façon dont les utilisateurs doivent utiliser le programme.

Chacun choisit ce qu'il veut faire avec ces chiffres. J'ai été tenté d'appeler les communiqués abc car c'est plutôt idiot de toute façon. Cela étant dit, ce que j'ai vu au cours des 25 dernières années de développement a tendance à fonctionner de cette façon. Disons que votre numéro de version est 1.2.3.

Le "1" indique une révision "majeure". Il s'agit généralement d'une version initiale, d'une modification importante de l'ensemble de fonctionnalités ou d'une réécriture de parties importantes du code. Une fois que l'ensemble de fonctionnalités est déterminé et au moins partiellement implémenté, vous passez au numéro suivant.

Le "2" indique une version dans une série. Souvent, nous utilisons cette position pour nous familiariser avec des fonctionnalités qui ne figuraient pas dans la dernière version majeure. Cette position (2) indique presque toujours un ajout de fonctionnalité, généralement avec des corrections de bogues.

Le "3" dans la plupart des magasins indique une version de correctif / correction de bogue. Presque jamais, du moins du côté commercial, cela n'indique un ajout de fonctionnalité significatif. Si des fonctionnalités apparaissent en position 3, c'est probablement parce que quelqu'un a vérifié quelque chose avant que nous sachions que nous devions faire une version de correction de bogue.

Au-delà de la position "3"? Je n'ai aucune idée de la raison pour laquelle les gens font ce genre de chose, cela devient encore plus déroutant.

Notamment certains des OSS là-bas jettent tout cela hors de wack. Par exemple, la version 10 de Trac est en fait 0.10.XX Je pense que beaucoup de gens dans le monde OSS manquent de confiance ou ne veulent tout simplement pas annoncer qu'ils ont fait une version majeure.

À partir du fichier C # AssemblyInfo.cs, vous pouvez voir ce qui suit:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision serait à mon avis.
Mais cela peut varier considérablement d'un produit à l'autre.

Major.minor.point.build généralement. Majeur et mineur sont explicites, point est une version pour quelques corrections de bugs mineurs et build est juste un identifiant de build.

Ouaip. Les versions majeures ajoutent de nouvelles fonctionnalités importantes, peuvent rompre la compatibilité ou avoir des dépendances très différentes, etc.

Les versions mineures ajoutent également des fonctionnalités, mais ce sont des versions portées plus petites, parfois réduites, de la version bêta majeure.

S'il existe un troisième composant de numéro de version, il s'agit généralement de corrections de bogues importantes et de correctifs de sécurité. S'il y en a plus, cela dépend vraiment tellement du produit qu'il est difficile de donner une réponse générale.

Le paradigme du correctif majeur release.minor release.bug est assez courant, je pense.

Dans certains contrats de soutien aux entreprises, il y a $$$ (ou rupture de responsabilité contractuelle) associé à la façon dont une version particulière est désignée. Un contrat, par exemple, peut donner droit à un client à un certain nombre de versions majeures dans une période donnée, ou promettre qu'il y aura moins de x nombre de versions mineures dans une période, ou que le support continuera à être disponible pour autant communiqués. Bien sûr, quel que soit le nombre de mots mis dans le contrat pour expliquer ce qu'est une version majeure par rapport à une version mineure, il est toujours subjectif et il y aura toujours des zones grises - ce qui conduit à la possibilité que l'éditeur de logiciel puisse jouer avec le système. battre ces dispositions contractuelles.

Les gens ne reconnaissent pas toujours la différence subtile entre les numéros de version comme 2.1, 2.0.1 ou 2.10 - demandez à un support technique combien de fois ils ont eu des problèmes avec cela. Les développeurs sont soucieux des détails et familiers avec les structures hiérarchiques, c'est donc un angle mort pour nous.

Si possible, exposez un numéro de version plus simple à vos clients.

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 correction de bogue doit préserver la compatibilité des binaires, des sources et de la 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é des sources.

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

J'ai écrit plus sur la justification ici .

Une combinaison de correctif majeur, mineur, correctif, build, correctif de sécurité, etc.

Les deux premiers sont majeurs et mineurs - le reste dépendra du projet, de l'entreprise et parfois de la communauté. Dans les OS comme FreeBSD, vous aurez 1.9.0.1_number pour représenter un correctif de sécurité.

Dépend un peu du langage, Delphi et C # par exemple ont des significations différentes.

Habituellement, les deux premiers nombres représentent une version majeure et une version mineure, c'est-à-dire 1.0 pour la première version réelle, 1.1 pour certaines corrections de bogues importantes et nouvelles fonctionnalités mineures, 2.0 pour une nouvelle version majeure.

Le troisième chiffre peut faire référence à une version ou révision "vraiment mineure". 1.0.1 est juste un très petit correctif à 1.0.0 par exemple. Mais il peut également porter le numéro de révision de votre système de contrôle de code source, ou un nombre toujours croissant qui s'incrémente à chaque build. Ou un horodatage.

Un peu plus de détails ici . "officiellement", dans .net, les 4 nombres sont "Major.Minor.Build.Revision", alors que dans Delphi il y a "Major.Minor.Release.Build". J'utilise "Major.Minor.ReallyMinor.SubversionRev" pour mon contrôle de version.

Généralement, les nombres sont au format version.major.minor.hotfix, et non des composants internes individuels. Ainsi, la v1.9.0.1 serait la version 1, la version majeure 9 (de la v1), la version mineure (de la v1.9) 0, le correctif 1 de (v1.9.0).

Le premier numéro est généralement appelé le numéro de version principale. Il est essentiellement utilisé pour désigner des changements significatifs entre les versions (c'est-à-dire que lorsque vous ajoutez de nombreuses nouvelles fonctionnalités, vous incrémentez la version principale). Les composants avec des versions majeures différentes du même produit ne sont probablement pas compatibles.

Le numéro suivant est le numéro de version mineure. Il peut représenter de nouvelles fonctionnalités, un certain nombre de corrections de bogues ou de petits changements d'architecture. Les composants du même produit qui diffèrent par le numéro de version mineure peuvent ou non fonctionner ensemble et ne devraient probablement pas.

Le suivant est généralement appelé le numéro de build. Cela peut être incrémenté quotidiennement, ou avec chaque build "publié", ou avec chaque build du tout. Il peut y avoir seulement de petites différences entre deux composants qui ne diffèrent que par le numéro de version et peuvent généralement bien fonctionner ensemble.

Le numéro final est généralement le numéro de révision. Souvent, cela est utilisé par un processus de construction automatique, ou lorsque vous faites des compilations jetables «uniques» pour les tests.

Lorsque vous incrémentez, vos numéros de version dépendent de vous, mais ils doivent toujours s'incrémenter ou rester les mêmes . Vous pouvez faire en sorte que tous les composants partagent le même numéro de version ou n'incrémenter le numéro de version que sur les composants modifiés.

Le numéro de version d'un logiciel complexe représente l'ensemble du package et est indépendant des numéros de version des pièces. La version 3.2.5 de Gizmo peut contenir la version 1.2.0 de Foo et la version 9.5.4 de Bar.

Lors de la création des numéros de version, utilisez-les comme suit:

1. Le premier numéro est la version principale. Si vous apportez des modifications importantes à l'interface utilisateur ou si vous avez besoin de casser des interfaces existantes (afin que vos utilisateurs devront changer leur code d'interface), vous devez passer à la nouvelle version principale.

2. Le deuxième chiffre doit indiquer que de nouvelles fonctionnalités ont été ajoutées ou que quelque chose fonctionne différemment en interne. (Par exemple, la base de données Oracle peut décider d'utiliser une stratégie différente pour récupérer les données, rendant la plupart des choses plus rapides et certaines choses plus lentes.) Les interfaces existantes devraient continuer à fonctionner et l'interface utilisateur devrait être reconnaissable.

3. La numérotation des versions appartient en outre à la personne qui écrit le logiciel - Oracle utilise cinq (!) Groupes, c'est-à-dire. une version Oracle est quelque chose comme 10.1.3.0.5. À partir du troisième groupe, vous ne devez introduire que des corrections de bogues ou des modifications mineures des fonctionnalités.

ceux qui varient le moins seraient les deux premiers, pour major.minor, après cela, il peut s'agir de n'importe quoi, de la construction, de la révision, de la publication à n'importe quel algorithme personnalisé (comme dans certains produits MS)

Chaque organisation / groupe a sa propre norme. L'important est que vous vous en teniez à la notation que vous choisissez, sinon vos clients seront confus. Cela dit, j'ai utilisé normalement 3 nombres:

x.yz.bbbbb. Où: x: est la version majeure (nouvelles fonctionnalités majeures) y: est le numéro de version mineure (petites nouvelles fonctionnalités, petites améliorations sans changements d'interface utilisateur) z: est le service pack (fondamentalement le même que xy mais avec quelques corrections de bogues bbbb: est le numéro de build et n'est vraiment visible que depuis la "boîte à propos" avec d'autres détails pour le support client. bbbb est un format gratuit et chaque produit peut utiliser le sien.

Voici ce que nous utilisons:

1. Premier chiffre = ère globale du système. Change tous les deux ans et représente généralement un changement fondamental de la technologie, des fonctionnalités client ou des deux.
2. Deuxième numéro = révision du schéma de base de données. Un incrément de ce nombre nécessite une migration de la base de données et est donc un changement significatif (ou les systèmes se répliquent et donc changer la structure de la base de données nécessite un processus de mise à niveau minutieux). Remet à 0 si le premier chiffre change.
3. Troisième chiffre = le logiciel ne change que. Cela peut généralement être implémenté client par client, car le schéma de la base de données reste inchangé. Remet à zéro si le deuxième nombre change.
4. Numéro de version de Subversion. Nous le remplissons automatiquement lors de la construction à l'aide de l'outil TortoiseSVN. Ce nombre ne se réinitialise jamais mais augmente continuellement. En utilisant cela, nous pouvons toujours recréer n'importe quelle version.

Ce système nous sert bien car chaque numéro a une fonction claire et importante. J'ai vu d'autres équipes se débattre avec la question des nombres majeurs / mineurs (à quel point un changement est majeur) et je n'en vois pas les avantages. Si vous n'avez pas besoin de suivre les révisions de la base de données, accédez simplement à un numéro de version à 3 ou 2 chiffres et simplifiez-vous la vie!

version: v1.9.0.1

où-

. v est l'abréviation de version. Cela varie d'une entreprise à l'autre en fonction de la nomenclature adoptée dans son organisation. Il peut être silencieux dans certaines organisations comme 1.9.0.1

. 1 indique la version principale, sera mis à jour sur la modification architecturale dans les piles d'applications, l'infrastructure (plate-forme) ou l'interface des réseaux exposés

. 9 incates minor, sera mis à jour sur l'activité comme l'ajout de nouveaux composants tels que l'interface utilisateur, l'api, la base de données, etc. sous une architecture spécifique

. 0 indique la fonctionnalité, sera mis à jour sur toutes les améliorations sur les composants existants (ui, api, base de données, etc.)

. 1 indique le compteur de construction pour toutes les phases majeures, mineures et caractéristiques. Il comprend également des correctifs post-production.