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

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

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é.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.