Que représentent généralement les numéros d'une version (c'est-à-dire v1.9.0.1)?
C’est peut-être une question idiote, mais j’ai toujours supposé que chaque nombre défini par une période représentait un seul composant du logiciel. Si c'est vrai, représentent-ils jamais quelque chose de différent? J'aimerais commencer à assigner 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.
En 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 une modification dans un champ de recherche, 1 fonctionnalité ajoutée, une collection de corrections de bugs)
0 : Publication de correctifs de bugs
1 : Numéro de compilation (le cas échéant): c'est pourquoi vous voyez le framework .NET utiliser quelque chose comme 2.0.4.2709.
Vous ne trouverez pas beaucoup d’applications descendant sur quatre niveaux, trois suffisent généralement.
Il y a la spécification de version sémantique
Voici le résumé de la version 2.0:
Avec un numéro de version MAJOR.MINOR.PATCH, incrémentez le:
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.Des étiquettes supplémentaires pour les métadonnées de pré-publication et de génération sont disponibles au format 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.Avril
Généralement, les nombres les plus à gauche (majeurs) indiquent une version majeure. Plus vous avancez à droite, plus le changement impliqué est petit.
major.minor [.maintenance [.build]]
Les nombres peuvent être utiles, comme décrit dans d’autres réponses, mais considérez qu’ils peuvent aussi ne pas avoir de sens ... Sun, vous connaissez Sun, Java: 1.2, 1.3, 1.4 1.5 ou 5, puis 6 . Dans le bon vieux Apple II les numéros de version signifiaient quelque chose. De nos jours, les gens abandonnent les numéros de version et utilisent des noms stupides tels que "Feisty fig" (ou quelque chose du genre), "hardy héron", "europa" et "ganymede". Bien sûr, cela est beaucoup moins utile, car vous allez manquer de lunes de Jupiter avant de cesser de changer de programme, et comme il n’existe aucun ordre évident, vous ne pouvez pas savoir lequel est le plus récent.
Plus il y a de points, plus la publication est mineure. Il n'y a pas de véritable 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, va dans ce sens:
1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...
La version 1.6 à 2.0 serait une version importante: fonctionnalités, modifications d’interface, modifications majeures des API, rupture de certains modèles et plugins 1.6, etc. La version 2.0 à 2.0.1 serait une version mineure, corrigeant peut-être un problème de sécurité. 2.0.2 à 2.1 serait une version importante - nouvelles fonctionnalités, en général.
Les chiffres peuvent signifier tout ce que vous voulez, bien qu'ils ne soient généralement pas liés à des composants individuels mais plutôt à des modifications majeures ou mineures par rapport à des modifications de maintenance dans votre version.
Découvrez ces ressources:
http://www.netbeans.org/community/guidelines/process.html
http://fr.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
À votre santé
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 différentes choses. Par exemple, certains systèmes augmentent certaines parties du numéro de version lorsqu'un format de fichier est modifié. 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.
Dans le fichier AssemblyInfo.cs C #, vous pouvez voir les éléments suivants:
// 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 ce que je suppose.
Mais cela peut varier considérablement entre les produits.
Cela dépend, mais la représentation typique est celle de major.minor.release.build.
Où:
- major 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 corrigée par les corrections de bugs
- build est un nombre indiquant le nombre de constructions que vous avez effectuées.
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 bugs. Puisqu'il s'agit de x.x.0.x, il s'agit de la version initiale de 1.9 et de la première version de cette version.
Vous pouvez également trouver de bonnes informations sur le article de Wikipedia sur le sujet }.
Major.Minor.Bugs
(Ou une variation à ce sujet)
Les bogues sont généralement des correctifs sans nouvelle fonctionnalité.
Minor est un changement qui ajoute de nouvelles fonctionnalités mais ne modifie pas le programme de manière majeure.
Major est un changement dans le programme qui casse l'ancienne fonctionnalité ou est si gros qu'il modifie en quelque sorte la manière dont les utilisateurs doivent utiliser le programme.
Tout le monde choisit ce qu'il veut faire avec ces chiffres. J'ai été tenté d'appeler les versions a.b.c 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'un grand jeu de fonctionnalités ou d'une réécriture de parties importantes du code. Une fois l'ensemble des fonctionnalités déterminé et au moins partiellement mis en œuvre, vous passez au numéro suivant.
Le "2" indique une libération dans une série. Nous utilisons souvent cette position pour nous occuper de fonctionnalités qui n’ont pas été intégrées à la dernière version majeure. Cette position (2) indique presque toujours une fonctionnalité ajoutée, généralement avec des corrections de bugs.
Le "3" dans la plupart des magasins indique une version de correctif/correction de bogue. Presque jamais, du moins du point de vue commercial, cela n'indique un ajout important de fonctionnalités. Si les 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 correction de bogue.
Au-delà de la position "3"? Je ne sais pas pourquoi les gens font ce genre de chose, ça devient encore plus confus.
Notamment, certains des logiciels libres jettent tout cela hors de l'ordinaire. Par exemple, la version 10 de Trac correspond en réalité à 0.10.X.X. Je pense que beaucoup de gens dans le monde de l'OSS manquent de confiance ou ne veulent tout simplement pas annoncer qu'ils ont une sortie majeure.
Les gens ne reconnaissent pas toujours la différence subtile entre les numéros de version tels que 2.1, 2.0.1 ou 2.10 - demandez à un membre du support technique combien de fois ils ont eu des problèmes avec cela. Les développeurs sont soucieux des détails et connaissent les structures hiérarchiques. Il s’agit donc d’un angle mort pour nous.
Si possible, exposez un numéro de version simplifié à vos clients.
Le paradigme du correctif majeur release.minor release.bug est assez commun, je pense.
Dans certains contrats de support aux entreprises, il existe un $$$ (ou une responsabilité en cas de rupture de contrat) associé à la manière dont une version donnée est désignée. Un contrat, par exemple, peut autoriser un client à obtenir un certain nombre de versions majeures au cours d'une période donnée ou à promettre qu'il y aura moins de x versions majeures au cours d'une période ou que l'assistance restera disponible pour de nombreuses autres. communiqués. Bien entendu, quel que soit le nombre de mots figurant dans le contrat pour expliquer ce qu’il faut faire par rapport à une version mineure, il est toujours subjectif et il y aura toujours des zones grises - ce qui laisse au vendeur un potentiel de pouvoir jouer vaincre ces dispositions contractuelles.
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 décomposer les trois formes.
J'ai écrit plus sur la raison ici .
Major.minor.point.build généralement. Les majeures et mineures sont explicites, Point est une version pour quelques corrections de bugs mineurs, et build est juste un identifiant de build.
Habituellement c'est:
MajorVersion.MinorVersion.Revision.Build
Ouaip. Les versions majeures ajoutent de nouvelles fonctionnalités, peuvent briser 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 plus petites, parfois simplifiées, 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 tellement du produit qu'il est difficile de donner une réponse générale.
Le premier numéro est généralement appelé numéro de version majeur. Il est essentiellement utilisé pour signaler des changements importants entre les versions (c’est-à-dire que lorsque vous ajoutez de nombreuses nouvelles fonctionnalités, vous incrémentez la version principale). Les composants avec différentes versions principales du même produit ne sont probablement pas compatibles.
Le numéro suivant est le numéro de version mineur. Il peut représenter de nouvelles fonctionnalités ou un certain nombre de corrections de bugs ou de petites modifications 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 prochain s'appelle généralement le numéro de build. Cela peut être incrémenté quotidiennement, ou avec chaque version "publiée", ou avec chaque version du tout. Il ne peut y avoir que de petites différences entre deux composants qui ne diffèrent que par le numéro de build 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 créez des versions uniques pour les tester.
Lorsque vous incrémentez vos numéros de version, cela dépend de vous, mais ils doivent toujours 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 incrémentez uniquement le numéro de version 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.
Lorsque vous créez des numéros de version, utilisez-les comme suit:
Le premier numéro est la version principale. Si vous apportez des modifications importantes à l'interface utilisateur ou devez casser des interfaces existantes (pour que vos utilisateurs aient à modifier leur code d'interface), vous devez passer à la nouvelle version principale.
Le deuxième numéro 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, ce qui accélère et ralentit la plupart des choses.) Les interfaces existantes doivent continuer à fonctionner et l'interface utilisateur doit être reconnaissable.
La numérotation des versions appartient ensuite à la personne qui écrit le logiciel - Oracle utilise cinq (!) Groupes, c.-à-d. une version Oracle ressemble à 10.1.3.0.5. À partir du troisième groupe, vous ne devez introduire que des corrections de bugs ou des modifications mineures des fonctionnalités.
ceux qui varient moins seraient les deux premiers, pour major.minor, après cela, il pourrait s'agir de tout, de la construction à la révision, de la publication à tous les algorithmes personnalisés (comme dans certains produits MS)
Voici ce que nous utilisons:
- Premier nombre = ère globale du système. Modifie tous les deux ans et représente généralement un changement fondamental de la technologie, des fonctionnalités du client ou des deux.
- Deuxième numéro = révision du schéma de base de données. Une augmentation de ce nombre nécessite une migration de la base de données, de même qu'une modification importante (ou que les systèmes sont répliqués et que, par conséquent, la structure de la base de données nécessite un processus de mise à niveau minutieux). Remet à 0 si le premier numéro change.
- Troisième numéro = le logiciel ne change que. Cela peut généralement être implémenté client par client car le schéma de base de données n'est pas modifié. Remet à zéro si le deuxième nombre change.
- Numéro de version de Subversion. Nous peuplons cela automatiquement lors de la construction à l'aide de l'outil TortoiseSVN. Ce nombre ne se réinitialise jamais mais s'incrémente 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 aux prises avec la question du numéro majeur/numéro mineur (quelle est l'ampleur d'un changement majeur) et je ne vois pas l'avantage à cela. Si vous n'avez pas besoin de suivre les révisions de la base de données, allez simplement à un numéro de version à 3 ou 2 chiffres et simplifiez-vous la vie!
Dans la version v1.9.0.1: Il s’agit du schéma de gestion de version explicite utilisé lorsque vous ne souhaitez pas utiliser le nom pour les versions préliminaires ou une compilation telle que -alpha, -beta.
1: Version majeure qui pourrait casser la compatibilité ascendante
9: Ajout de nouvelles fonctionnalités pour prendre en charge votre application et compatibilité avec les versions antérieures.
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 gestion des versions. Veuillez vous reporter à la version sémantique [semver2.0] https://semver.org/
Chaque organisation/groupe a sa propre norme. La chose importante est que vous vous en teniez à la notation que vous choisissez, sinon vos clients seraient confus. Cela dit, j'ai utilisé normalement 3 chiffres:
x.yz.bbbbb. Où: X: est la version majeure (nouvelles fonctionnalités majeures) Y: est le numéro de version mineure (petites nouvelles, petites améliorations sans modifications de l'interface utilisateur) Z: est le service pack comme xy mais avec quelques corrections de bugs bbbb: est le numéro de build et n’est vraiment visible que dans la zone "à propos de" avec d’autres détails pour le support client.
Une combinaison de 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 un système d'exploitation 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 numéros représentent une version majeure et une version mineure, c’est-à-dire 1.0 pour la première version réelle, 1.1 pour des corrections de bogues importantes et de nouvelles fonctionnalités mineures, 2.0 pour une nouvelle version.
Le troisième numéro peut faire référence à une version "vraiment mineure" ou à une révision. 1.0.1 est juste un très petit bug à 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 numéro incrémenté à chaque fois. Ou un horodatage.
Un peu plus en détail ici . "officiellement", en .net, les 4 chiffres 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 pas des composants internes individuels. La v1.9.0.1 correspond donc à la version 1, version majeure 9 (de v1), version mineure (de v1.9) 0, correctif 1 de (v1.9.0).