Quel est exactement le numéro de build dans MAJOR.MINOR.BUILDNUMBER.REVISION

Je « ne lai jamais vu écrit sous cette forme. Là où je travaille, nous utilisons le formulaire MAJOR.MINOR.REVISION.BUILDNUMBER, où:

• MAJOR est une version majeure (généralement de nombreuses nouvelles fonctionnalités ou modifications apportées à linterface utilisateur ou OS sous-jacent)
• MINOR est une version mineure (peut-être quelques nouvelles fonctionnalités) sur une version majeure précédente
• REVISION est généralement un correctif pour une version mineure précédente (pas de nouvelle fonctionnalité)
• BUILDNUMBER est incrémenté pour chaque dernière version dune révision.

Par exemple, une révision peut être publiée pour QA (contrôle qualité), et ils reviennent avec un problème qui nécessite un changement. Le bogue serait corrigé et renvoyé au contrôle qualité avec le même numéro de REVISION, mais avec un BUILDNUMBER incrémenté.

Commentaires

• +1: That ‘ est à peu près comme je lai ‘ vu partout ailleurs aussi. ‘ jai vu et aimé la façon dont certaines entreprises utilisent simplement un horodatage pour le BUILDNUMBER.
• +1:  » MAJOR.MINOR.REVISION.BUILDNUMBER  » est compréhensible et logique. Jai vu le formulaire BUILDNUMBER.REVISION sur le site MSDN (lien mis à jour en question) et cela ma totalement dérouté.
• Odd. Je mattendrais à ce que la dernière révision ait le plus de sens – ‘ est le numéro qui changera (probablement) le plus.
• @Izkata, en fait la version Cest le nombre qui change le plus, du moins la façon dont nous lutilisons actuellement dans mon contrat principal qui utilise un contrôle de version strict parce que nous fabriquons des dispositifs médicaux. Une révision mise à jour indique quil y a eu un correctif au logiciel précédent, qui doit être testé par QA (Quality Assurance). Il sagit dun département complètement distinct qui effectue des tests approfondis pendant trois jours (conformément aux directives de la FDA). Sils trouvent des problèmes, des modifications de code supplémentaires peuvent être nécessaires, nécessitant une nouvelle compilation (recompilation et liaison), puis un nouveau test, mais le numéro de révision reste le même.
• @tcrosley Je suppose que ‘ est un cas de terminologie peu claire. Je pensais à des révisions dans le contrôle de version.

Toute la confusion vient du une sémantique différente que MS utilise pour « Build number » et en particulier « Revision ». Les termes signifient simplement des choses différentes.

La plupart des gens (moi y compris) utilisent un schéma de numérotation de version sémantique où vous obtenez simplement un numéro de BUILD plus élevé chaque fois que vous devez faire une nouvelle construction pour une raison quelconque. Pour nous, un correctif est considéré comme une simple modification de code et la partie BUILD augmente automatiquement à chaque exécution de CI. Les modules avec le même MAJ.MIN.REV sont considérés comme interchangeables, et le BUILD vous indique lequel est le plus récent.

Lincrémentation de REVISION, cependant, indique une nouvelle branche de version permanente, cest pourquoi nous la plaçons avant BUILD.Linconvénient de cette approche est que nous pourrions obtenir la séquence dévénements suivante:

• numéro de validation 4711: Alice a ajouté la fonctionnalité A
• CI produit la version 1.2.3.100
• commit numéro 4712: Bob a modifié la fonctionnalité B
• commit numéro 4713: Alice a fixé la fonctionnalité A (le « correctif »)
• CI produit la version 1.2.3.101

Comme vous pouvez le voir, le correctif nest pas le seul changement contenu dans le prochain build, la modification de Bob fait également partie de cette build. Si vous voulez stabiliser la branche actuelle, vous risquez de rencontrer des problèmes car vous ne pouvez jamais être sûr que Bob vient dajouter un tas de bogues.

MS utilise les deux termes différemment. Le numéro de BUILD nest pas automatiquement incrémenté, mais il peut être considéré comme une sorte de branche de version, pour figer le code utilisé pour une version particulière du code. La RÉVISION indique des changements « chauds » supplémentaires appliqués à cette branche BUILD. La séquence serait donc la suivante:

• numéro de commit 4711: Alice a ajouté la fonctionnalité A au tronc / maître
• Carl crée la branche de construction 1.2.100
• CI produit la version 1.2.100.0
• numéro de commit 4712: Bob a modifié la fonction B dans le tronc / maître
• numéro de commit 4713: Alice a fixé la fonction A dans la branche 1.2.100
• CI produit la version 1.2.100.1

Le terme REVISION peut faire référence à

• un produit révision (cest ainsi que la plupart des gens lutilisent)
• révision dune version quotidienne (cest ce que fait MS)

La principale différence entre les deux processus est de savoir si vous souhaitez ou non pouvoir appliquer des correctifs aux builds CI et donc, à quel stade du processus la branche est créée. Cet aspect devient important lorsque vous souhaitez pouvoir choisir une version particulière à tout moment après que tous les tests ont réussi et promouvoir exactement cette version à la prochaine version officielle de votre produit.

Dans notre cas, loutil CI crée une balise de référentiel, donc nous avons toujours les informations nécessaires prêtes à être utilisées, quand cela est nécessaire. Avec SVN, cela devient encore plus simple, car les balises et les branches sont implémentées exactement de la même manière – une balise nest rien de plus quune branche située sous /tags.

Voir également

De la section FAQ sur Stratégie de branchement TFS :

Dans quelle branche dois-je corriger le ticket P1 (hotfix)?

• Le P1 doit être corrigé dans la branche la plus proche de la base de code exécutée en Production. Dans ce cas, le P1 doit être fixé dans la branche Prod. En appliquant le correctif dans nimporte quelle autre branche et en déployant les modifications en production, vous risquez de publier du code semi-fini ou non testé à partir des itérations suivantes.

• Vous pouvez maintenant discuter si cest le cas. sûr de travailler directement contre la branche Prod, détrompez-vous, un P1 qui nécessite une attention immédiate ne devrait pas être un problème fondamental dans le système. Dans le cas où il sagit dun problème fondamental, il doit être ajouté au backlog du produit car il peut nécessiter une analyse plus approfondie et une discussion avec le client.

Une autre bonne lecture est le Guide de branchement TFS

Commentaires

• Cest une excellente réponse! +1

Microsoft décrit lobjectif de chaque composant dun numéro de version .NET dans sa documentation MSDN pour la classe Version. Voici la partie pertinente:

major.minor [.build [.revision]]

Les composants sont utilisés par convention comme suit:

Major: les assemblys avec le même nom mais différentes versions majeures ne sont pas interchangeables. Un numéro de version plus élevé peut indiquer une réécriture majeure dun produit où la compatibilité descendante ne peut pas être supposée.

Mineure: Si le nom et le numéro de version majeure de deux assemblys sont identiques, mais que le numéro de version mineure est différent, cela indique une amélioration significative avec lintention de compatibilité ascendante. Ce numéro de version mineure plus élevé peut indiquer une version intermédiaire dun produit ou une nouvelle version entièrement rétrocompatible dun produit.

Version: une différence de numéro de version représente une recompilation de la même source. Différents numéros de version peuvent être utilisés lorsque le processeur, la plate-forme ou le compilateur change.

Révision: les assemblys avec le même nom, les mêmes numéros de version majeure et mineure, mais des révisions différentes sont censées être entièrement interchangeables. Un numéro de révision plus élevé peut être utilisé dans une version qui corrige une faille de sécurité dans un assembly précédemment publié.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Commentaires

• Cela me déroute pourquoi personne ne connaît ce standard, chaque réponse ici prétend que la construction va à la fin et ne ‘ t comprendre que la révision est très simple; cela signifie correctif. Vous publiez une version, puis créez dautres versions, mais lorsque vous devez revenir en arrière et corriger cette version, vous mettez à jour la révision pour montrer que la version particulière qui a été publiée a été modifiée pour une nouvelle version
• +1 pour une réponse qui a un numéro de build justifiable. Le simple fait dincrémenter le nombre est plutôt inutile si la révision reste la même (à moins que vous nayez un système de construction insensé qui dépend du temps). Utiliser le numéro de build pour signaler le compilateur, les plates-formes, etc. est utile.
• Build comme recompilation of the same source semble être un point important qui est oublié. Si ‘ est un changement de code (cela ‘ t nécessite une toute nouvelle augmentation majeure / mineure), alors Revision doit également être modifié.
• @PeterX Comme dans le cas des modifications spécifiques à la build lors du reciblage?
•  » Une différence de numéro de build représente une recompilation de la même source  » semble contredire la documentation. Une fois que vous faites une révision, ce nest plus la même source. Avoir BUILD avant REVISION na de sens que si une révision est spécifique à une build représentant un  » changement de processeur, de plate-forme ou de compilateur « . Donc, je suppose que ce que la plupart considèrent comme une bosse de RÉVISION devrait vraiment être une bosse MINEURE lors de lutilisation de ces descriptions. Bien que la documentation mentionne lutilisation de REVISION pour les correctifs, mais je suppose que les correctifs sappliqueraient à toutes les versions et devraient donc être une bosse MINEURE. Je veux juste une cohérence logique !!

Il y a au moins deux choses différentes que je pourrais imaginez le numéro de build référençant:

1. Version du contrôle de source qui était sortie. Par exemple, sil y avait une version de la révision # 12345, cela peut être suivi en lui donnant le numéro de version et si elle est corrigée, cest là que les révisions peuvent augmenter car ce nest pas une nouvelle fonctionnalité qui augmenterait les versions majeures ou mineures et le numéro de build doit être mémorisé au cas où quelquun voudrait lexécuter à nouveau.

2. Identificateur du serveur dintégration continue. Dans ce cas, le serveur CI peut numéroter chaque build quil exécute et donc le numéro de construction est ce quune construction réussie obtient et la partie révision nest pas nécessaire dans ce scénario.

Il peut y en avoir dautres que je ne connais pas, mais ce sont les grands que je connais en ce qui concerne les nombres sur des bases de code.

Commentaires

• +1 pour # 1. Jaime utiliser le révision du contrôle de code source #, car il est beaucoup plus facile de rechercher les bogues signalés par rapport à cette version dans le contrôle de code source.
• @MasonWheeler: fonctionne très bien si vous êtes sur SVN. obtient un écureuil y. Ce serait une chose qui me manque le plus à propos de svn que je ‘ ajouterai.

Un numéro de build est généralement incrémenté à chaque build, il est donc unique.

Pour des raisons de simplicité, certains réinitialisent le numéro de build chaque fois que les nombres MAJEURS ou MINEURS sont modifiés.

La plupart des moteurs dintégration continue autorisent la génération automatique de numéros de build uniques.

La révision peut être utilisée pour les correctifs du construit. Disons que 2 équipes travaillent sur un produit.

Léquipe 1 est la principale équipe de développement et produit des versions nocturnes avec le schéma de version 1.0.X.0 suivant, où X est incrémenté. Maintenant, ils sont à la version 1.0.50.0. Léquipe 2 prend une version de temps en temps. Disons quils prennent la version de la semaine dernière qui est 1.0.43.0 et commencent à lutiliser. Léquipe 1 passe à 1.0.51.0 quand léquipe 2 trouve un problème dans 1.0.43.0.

Maintenant léquipe 1 va prenez cette version (43), corrigez le problème et fournissez à léquipe 2 la version 1.0.43.1. Le correctif pourrait également être propagé dans la version principale, donc le changement apparaîtra dans la version 1.0.52.0.

Hope cest clair et utile.

* La révision est utile lorsque toutes les personnes impliquées dans le projet nutilisent pas la même version et que vous devez corriger des versions spécifiques.

Permettez-moi de dire simplement comment je le vois et lutilise ….

ProgramName version major.minor.build.revision

major: Pour moi, cest le projet actuel sur lequel je travaille. Le numéro ne changera pas tant que je naurai pas démarré un nouveau projet du même nom de programme. Cela signifie que jécrirai littéralement un nouveau programme du même genre (exemple: access v1 – access v-2 – access v-3 * tout le même programme mais complètement réécrit).

mineur: Cela signifie que je suis ad ding fonctionnalité au projet publié en cours.Par exemple, jai peut-être ajouté la possibilité dimprimer un reçu ou ajouté la possibilité dimporter des images. Fondamentalement, des fonctionnalités supplémentaires que je veux ajouter maintenant et ne pas attendre la prochaine version majeure pour le faire.

build: Ceci que jutilise pour indiquer de très petits changements dans la version major.minor publiée. Cela pourrait être un changement dans la mise en page, le jeu de couleurs, etc. projet en cours et un bug survient. Ce bogue doit être corrigé et publié. Cela signifie simplement que je corrige ce que jai déjà publié pour quil fonctionne correctement. Jutiliserais également ceci si je travaille sur une nouvelle version, un nouvel ajout ou ai commencé une nouvelle version majeure. La version publiée doit évidemment être corrigée pendant que nous attendons la prochaine version majeure, mineure ou build.

Ainsi, de cette manière, un projet terminé ou bloqué peut toujours être corrigé et rendu utilisable jusquà la prochaine version. publié.

Jespère que cela permettra à quelquun de mieux comprendre comment ce type de gestion des versions fonctionnerait (ou devrait) fonctionner. Pour moi, cest la seule définition et pratique qui ait un sens réel lors de lutilisation de ce type de contrôle de version.

Je nai jamais vu un numéro de build que le dernier numéro de lID de version. Je ne sais pas comment vous auriez pu apporter une révision à un numéro de build. Je suppose que si vous avez changé certaines des ressources non intégrées ( icônes, script DB, etc.), peut-être, mais la plupart des projets sur lesquels j’ai travaillé récemment ont également tous ces éléments sous contrôle de version, de sorte que le processus de construction les récupère lors de la création du programme d’installation / version. Jaime les numéros de build horodatés, mais pas tout à fait comme @David le décrit (jaime major.minor.revision.HHMM). Cependant, là où je travaille, nous utilisons simplement un numéro séquentiel généré par notre serveur de construction.

Cest ce que vous voulez ça doit être. Jai tendance à utiliser year.month.day.hhmm pour ma major.minor.build.revision. Si je produis plus d un par minute, quelque chose ne va pas. vous pouvez simplement utiliser un simple incrément, ou j « ai vu des générateurs élaborés pour eux. Quest-ce que vous voulez que ce soit. Ce quils doivent faire est de faire en sorte que vous arriviez à la source habituée à créer cette sortie, donc tout ce qui vous permet de le faire.

Notre équipe utilise le troisième nombre (révision) comme numéro de révision du référentiel Subversion. Nous utilisons le quatrième numéro (build) comme numéro de build de notre serveur dintégration continue TeamCity qui crée réellement la build. TeamCity crée un nouveau fichier AssemblyInfo avec les bons # à lintérieur pendant le processus de build.

Comme jkohlhepp, nous utilisons la troisième partie de la version pour afficher le numéro de révision dans SubVersion et la quatrième pour afficher le numéro de build de notre serveur dintégration continue (Jenkins pour nous). Cela nous donne plusieurs avantages – avoir le numéro de version défini par notre serveur CI supprime une étape manuelle qui pourrait autrement être accidentelle manqué; il est facile de vérifier quun développeur na pas fait une version effrontée de son PC de développement (ce qui ferait en sorte que ces nombres soient zéro); et cela nous permet de relier nimporte quel logiciel à la fois au code quil a été généré à partir de et le travail CI qui la construit, simplement en regardant le numéro de version – que nous trouvons parfois très utile.

Les deux derniers chiffres sont le numéro de build total

1.01.2.1234

le numéro de build est 2.1234 mais la plupart des gens utiliseront simplement 1234 car la partie 2 ne change pas fréquemment.

Commentaires

• LOP demande quel est le numéro de build, pas quel est le numéro de build dans lID de révision.