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


55

Ce que je pense des numéros de build, c’est que chaque fois qu’un nouveau build est créé chaque nuit, un nouveau BUILDNUMBER est généré et attribué à ce build. Donc, pour mon application de version 7.0, les versions nocturnes seront 7.0.1, 7.0.2 et ainsi de suite. Est-ce vrai? Alors à quoi sert une révision après le numéro de build? Ou la partie REVISION est-elle incrémentée après chaque construction nocturne? Je suis un peu confus ici ... parlons-nous de chaque bâtiment nocturne comme étant un bâtiment ?

Le format est mentionné ici: AssemblyVersion - MSDN


Ensuite, vous pouvez utiliser la date comme numéro de build!

2
Build: Chaque nouvelle version du système, Revision: Hotfix ou "révision" d’une version publiée, c’est pourquoi elle modifie la version de la version; Votre version actuelle est peut-être la version 2.2.12.0, mais la version publiée peut être la version 2.2.8.0. Lorsque vous devez corriger ce correctif, vous extrayez le code source de la version 2.2.8, vous le révisez et la version 2.2.8.1 est mise à jour 3 mois plus tard. 2.2.16.0 mais un client est toujours sur 2.2.8.1 et rencontre un autre bogue, vous extrayez le code de la version 2.2.8.1 et vous le révisez pour corriger le bogue, puis vous le publiez sous la version 2.2.8.2
Jimmy Hoffa,

Réponses:


57

Je ne l'ai 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 à l'interface utilisateur ou au système d'exploitation sous-jacent), MINOR étant 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 (aucune nouvelle fonctionnalité) et BUILDNUMBER est incrémenté pour chaque version la plus récente d’une révision.

Par exemple, une révision peut être transmise à QA (contrôle de la qualité), qui revient avec un problème nécessitant une modification. Le bogue serait corrigé et publié de nouveau dans QA avec le même numéro REVISION, mais un BUILDNUMBER incrémenté.


+1: C'est à peu près ce que j'ai vu partout ailleurs. J'ai vu et apprécié la manière dont certaines entreprises utilisent simplement un tampon DateTime pour BUILDNUMBER.
Steven Evers

4
+1: Le formulaire "MAJOR.MINOR.REVISION.BUILDNUMBER" est compréhensible et a du sens. J'ai vu le formulaire BUILDNUMBER.REVISION sur le site MSDN (lien mis à jour en question) et cela m'a complètement dérouté.
A9S6

1
Impair. Je m'attendrais à ce que la révision soit la dernière à avoir le plus de sens - c'est le nombre qui changera (probablement) le plus.
Izkata

1
@ Izkata, ce sont les modifications de numéro de version qui changent le plus, tout comme notre contrat principal actuel, qui utilise un contrôle de version strict, car nous fabriquons des dispositifs médicaux. Une révision mise à jour indique qu'il y a eu un correctif au logiciel précédent, qui doit être testé par QA (Quality Assurance). Il s’agit d’un service totalement distinct qui effectue des tests approfondis pendant trois jours (conformément aux directives de la FDA). S'ils rencontrent des problèmes, des modifications supplémentaires du code peuvent s'avérer nécessaires, nécessitant une nouvelle construction (recompilation et lien), puis un nouveau test, mais le numéro de révision reste le même.
Tcrosley

@tcrosley Je suppose que c'est un cas de terminologie floue. Je pensais aux révisions dans le contrôle de version.
Izkata

19

Toute la confusion provient des différentes sémantiques que MS utilise pour "Numéro de construction" et en particulier "Révision". Les termes signifient simplement différentes choses.

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

Incrémenter REVISION, cependant, indique une nouvelle branche de publication permanente, c'est pourquoi nous la plaçons avant BUILD. L'inconvénient de cette approche est que nous pourrions obtenir la séquence d'événements suivante:

  • numéro de commit 4711: ajout de la fonctionnalité A par Alice
  • CI produit la version 1.2.3.100
  • numéro de commit 4712: fonctionnalité modifiée par Bob B
  • numéro de commit 4713: fonctionnalité fixe Alice A (le "correctif")
  • CI produit la version 1.2.3.101

major.minor.revision.build

Comme vous pouvez le constater, le correctif logiciel n'est pas le seul changement contenu dans la prochaine version, la modification de Bob en fait également partie. Si vous souhaitez stabiliser la branche actuelle, vous risquez de rencontrer des problèmes, car vous ne pouvez jamais savoir avec certitude si Bob a simplement ajouté un tas de bugs.

MS utilise les deux termes différemment. Le numéro BUILD n’est pas automatiquement incrémenté; on peut plutôt le considérer comme une sorte de branche de publication, afin de geler le code utilisé pour une version particulière du code. La REVISION indique des modifications "à chaud" supplémentaires appliquées à cette branche BUILD. La séquence serait donc la suivante:

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

major.minor.build.revision

Le terme REVISION peut désigner

  • une révision de produit (c'est comme ça que la plupart des gens l'utilisent)
  • une révision d'un build quotidien particulier (c'est ce que fait MS)

La principale différence entre les deux processus réside dans le fait que vous souhaitiez ou non pouvoir appliquer des correctifs aux générations de CI et par conséquent à quel moment du processus la branche est créée. Cet aspect devient important lorsque vous souhaitez pouvoir sélectionner une version particulière à tout moment une fois tous les tests réussis et promouvoir exactement cette version dans la prochaine version officielle de votre produit.

Dans notre cas, l’outil CI crée une balise de référentiel, nous avons donc toujours les informations nécessaires prêtes à être utilisées, le cas échéant. Avec SVN, cela devient encore plus simple, car les balises et les branches sont mises en œuvre exactement de la même manière - une balise n’est autre chose qu’une branche située sous /tags.

Voir également

Dans la section FAQ de la stratégie de création de branche TFS :

Dans quelle succursale dois-je réparer le ticket P1 (correctif)?

  • Le fichier P1 doit être corrigé dans la branche la plus proche de la base de code exécutée dans Production. Dans ce cas, le P1 doit être fixé dans la branche Prod. En appliquant le correctif dans toute autre branche et en appliquant les modifications apportées à la production, vous risquez de libérer du code semi-fini ou non testé lors des itérations suivantes.

  • Vous pouvez maintenant affirmer que s'il est sûr de travailler directement avec la branche Prod, détrompez-vous, un P1 qui requiert une attention immédiate ne devrait pas être un problème fondamental du système. S'il s'agit d'un problème fondamental, il convient de l'ajouter au carnet de 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


C'est une excellente réponse! +1
Lankymart

16

Microsoft décrit l'objectif de chaque composant d'un numéro de version .NET dans sa documentation MSDN pour la Versionclasse. Voici la partie pertinente:

major.minor [.build [.revision]]

Les composants sont utilisés par convention comme suit:

Major: les assemblages portant le même nom mais des versions majeures différentes ne sont pas interchangeables. Un numéro de version plus élevé peut indiquer une réécriture majeure d'un produit pour lequel la compatibilité en amont ne peut pas être assumé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 dans un souci de compatibilité ascendante. Ce numéro de version mineure supérieur peut indiquer une version ponctuelle d'un produit ou une nouvelle version d'un produit entièrement compatible avec les versions antérieures.

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

Révision: ensembles portant le même nom, les mêmes numéros de version majeurs et mineurs, mais différentes révisions sont destinées à être totalement interchangeables. Un numéro de révision plus élevé peut être utilisé dans une version qui corrige une faille de sécurité dans un assemblage précédemment publié.

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


9
Cela me laisse perplexe de savoir pourquoi personne ne connaît cette norme. Chaque réponse ici prétend que la construction va à la fin et ne comprend pas que la révision est très simple. cela signifie un correctif. Vous publiez une version, puis créez d'autres versions, mais lorsque vous devez corriger cette version, vous mettez à jour la révision pour indiquer que la version qui a été publiée a été modifiée pour une nouvelle version
Jimmy Hoffa

2
+1 pour une réponse qui a un numéro de build justifiable. Incrémenter simplement le nombre est plutôt inutile si la révision reste la même (sauf si vous avez un système de construction insensé qui dépend du temps). Utiliser le numéro de construction pour indiquer quels compilateurs, plateformes, etc. sont utiles.
Thomas Eding

1
Buildcomme recompilation of the same sourcesemble être un point important qui est manqué. S'il s'agit d'un changement de code (qui ne nécessite pas une nouvelle augmentation majeure / mineure), il Revisiondoit également être modifié.
PeterX

@ PeterX Comme dans le cas de modifications spécifiques à la construction lors du re-ciblage?
Samis

4

Il y a au moins deux choses différentes que je pourrais imaginer dans le référencement du numéro de build:

  1. Version du contrôle source qui a été publiée. Par exemple, s'il y a eu une version de révision n ° 12345, le numéro de build peut être utilisé. Si les correctifs sont corrigés, les révisions peuvent augmenter car il ne s'agit pas d'une nouvelle fonctionnalité qui augmenterait les versions majeures ou mineures. et le numéro de build doit être gardé en mémoire au cas où quelqu'un voudrait l'exécuter à nouveau.

  2. Identifiant de serveur d'intégration continue. Dans ce cas, le serveur CI peut numéroter chaque construction qu'il exécute. Le numéro de construction correspond donc à celui d'une construction réussie et la partie révision n'est pas nécessaire dans ce scénario.

Il y en a peut-être d'autres que je ne connais pas, mais ce sont les grands que je connais quand il s'agit de chiffres sur des bases de codes.


4
+1 pour # 1. J'aime utiliser le numéro de révision du contrôle de code source, car il est beaucoup plus facile de rechercher les bogues rapportés à cette version dans le contrôle de code source.
Mason Wheeler

@MasonWheeler: fonctionne très bien si vous êtes sur SVN. Mais quand vous arrivez à la terre, ça devient insolent. Ce serait une chose qui me manque le plus à propos de svn, je vais l'ajouter.
Wyatt Barnett

3

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

Par souci de simplicité, certains réinitialisent le numéro de build chaque fois que les numéros MAJOR ou MINOR sont modifiés.

La plupart des moteurs d'intégration continue permettent des numéros de build uniques générés automatiquement.


2

La révision peut être utilisée pour les patchs des builds. Disons que 2 équipes travaillent sur un produit.

L'équipe 1 est la principale équipe de développement et produit chaque génération avec la version 1.0.X.0 suivante, où X est incrémenté. Ils sont maintenant à la version 1.0.50.0. L’équipe 2 prend une version de temps en temps. Supposons qu'ils prennent la version 1.0.43.0 de la semaine dernière et commencent à l'utiliser. L'équipe 1 avance à 1.0.51.0 lorsque l'équipe 2 trouve un problème dans 1.0.43.0.

Maintenant, l’équipe 1 prendra cette version (43), corrigera le problème et fournira à l’équipe 2 la version 1.0.43.1. Le correctif peut également être propagé dans la construction principale. Le changement apparaîtra donc dans 1.0.52.0.

J'espère que cela est clair et utile.

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


2

Laissez-moi juste dire comment je vois et utilise ...

Version ProgramName major.minor.build.revision

major: Pour moi, c'est le projet actuel sur lequel je travaille. Le numéro ne changera pas tant que je n'aurai pas démarré un nouveau projet portant le même nom de programme. Cela signifie que je vais littéralement écrire un nouveau programme du même genre (exemple: access v1 - access v-2 - access v-3 * tous les mêmes programmes mais complètement réécrits).

mineur: Cela signifie que j'ajoute des fonctionnalités au projet publié actuel. Par exemple, j'ai peut-être ajouté la possibilité d'imprimer un reçu ou d'importer des images. Essentiellement, des fonctionnalités supplémentaires que je veux ajouter maintenant sans attendre la prochaine version majeure.

build: Ceci je l’utilise pour indiquer de très petits changements dans la version major.minor publiée. Cela pourrait être un changement dans la mise en page, la palette de couleurs, etc.

revision: Ceci je l’utilise pour indiquer un correctif dans le major.minor.build actuellement publié - Il arrive que je ne progresse pas dans le projet en cours et qu’un bogue se produise. Ce bogue doit être corrigé et publié. Cela signifie simplement que je répare ce que j'ai déjà publié pour qu'il fonctionne correctement. J'utiliserais aussi ceci si je travaille sur une nouvelle version, une nouvelle addition ou si je commence une nouvelle version majeure. La version publiée doit évidemment être corrigée en attendant la prochaine version majeure, mineure ou de construction.

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

J'espère que cela donne à quelqu'un une meilleure compréhension de la façon dont ce type de gestion des versions fonctionnerait (ou devrait). Pour moi, c’est la seule définition et la seule pratique qui ait un sens réel lorsque vous utilisez ce type de gestion des versions.


1

Je n'ai jamais vu un numéro de build comme dernier numéro de l'ID de version. Je ne sais pas comment vous pourriez proposer une révision d'un numéro de build. Je suppose que si vous avez modifié certaines des ressources non construites (icônes, script de base de données, etc.), peut-être, mais la plupart des projets sur lesquels j'ai travaillé récemment ont tous ces éléments sous contrôle de version, de sorte que le processus de construction les récupère lorsque faire l'installateur / release. J'aime les numéros de build horodatés, bien que pas tout à fait comme décrit par @David (j'aime major.minor.revision.HHMM). Cependant, là où je travaille, nous utilisons simplement un numéro séquentiel que notre serveur de génération génère.


1

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 version de notre serveur d'inté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 sinon être manquée par inadvertance; il est facile de vérifier qu'un développeur n'a pas publié de version effrontée à partir de son PC de développement (ce qui ferait que ces chiffres seraient nuls); et cela nous permet de relier n'importe quel logiciel au code à partir duquel il a été généré et au travail de CI qui l'a construit, il suffit de regarder le numéro de version - ce qui nous paraît parfois très utile.


0

C'est ce que vous voulez que ce soit. J'ai tendance à utiliser year.month.day.hhmm pour mon major.minor.build.revision. Si je produis plus d'une minute, quelque chose ne va pas. vous pouvez simplement utiliser un simple incrément, ou j'ai vu quelques générateurs élaborés pour eux. Que voulez- vous que ce soit. Ce qu’ils doivent faire, c’est faire en sorte que vous obteniez la source utilisée pour créer cette sortie, donc tout ce qui vous permet de le faire.


0

Les deux derniers chiffres représentent le nombre total de build

1.01.2.1234

le numéro de version est 2.1234 mais la plupart des gens n'utiliseront que 1234 car la partie 2 ne change pas souvent.


1
L'OP demande quel est le numéro de build et non pas le numéro de build dans l'ID de révision.
Kiamlaluno

0

Notre équipe utilise le troisième numéro (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 d’intégration continue TeamCity qui crée effectivement la build. TeamCity crée un nouveau fichier AssemblyInfo contenant les bons numéros lors du processus de construction.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.