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'une nouvelle build nocturne est créée, un nouveau BUILDNUMBER est généré et affecté à cette build. Donc, pour mon application de version 7.0, les versions nocturnes seront 7.0.1, 7.0.2 et ainsi de suite. En est-il ainsi? 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 build nocturne? Je suis un peu confus ici ... faisons-nous référence à chaque build nocturne comme [~ # ~] build [~ # ~] ?
Le format est mentionné ici: AssemblyVersion - MSDN
Je ne l'ai jamais vu écrit sous cette forme. Lorsque 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 de l'interface utilisateur ou du système d'exploitation 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é), et BUILDNUMBER est incrémenté pour chaque dernière version d'une révision.
Par exemple, une révision peut être publiée dans QA (contrôle qualité), et ils reviennent avec un problème qui nécessite une modification. Le bogue serait corrigé et renvoyé à QA avec le même numéro de RÉVISION, mais un BUILDNUMBER incrémenté.
Toute la confusion vient des différentes sémantiques que MS utilise pour "Build number" et surtout "Revision". Les termes signifient simplement des choses différentes.
La plupart des gens (moi y compris) utilisent un schéma de numérotation des versions sémantiques où vous obtenez simplement un numéro BUILD plus élevé chaque fois que vous devez faire une nouvelle construction pour une raison quelconque. Pour nous, un correctif est considéré comme juste un autre changement 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.
L'incrémentation de REVISION, cependant, indique une nouvelle branche de version 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:
- commit numéro 4711: Alice a ajouté la fonction A
- CI produit la version 1.2.3.100
- commit numéro 4712: Bob a modifié la fonction B
- commit numéro 4713: fonctionnalité fixe A d'Alice (le "correctif")
- CI produit la version 1.2.3.101
Comme vous pouvez le voir, le correctif n'est pas le seul changement contenu dans la prochaine génération, la modification de Bob fait également partie de cette génération. Si vous souhaitez stabiliser la branche actuelle, vous pouvez rencontrer des problèmes car vous ne pouvez jamais être sûr que Bob ait simplement ajouté un tas de bogues.
MS utilise les deux termes différemment. Le numéro BUILD n'est pas automatiquement incrémenté, mais il peut être considéré comme une sorte de branche de publication, pour geler le code utilisé pour une version particulière du code. La RÉVISION indique des changements "à chaud" supplémentaires appliqués à cette branche BUILD. La séquence serait donc la suivante:
- commit numéro 4711: Alice a ajouté la fonctionnalité A au coffre/maître
- Carl crée une branche de construction
1.2.100 - CI produit la version 1.2.100.0
- commit numéro 4712: Bob a modifié la fonction B dans le coffre/maître
- commit numéro 4713: fonction fixe Alice A dans le
1.2.100branche - CI produit la version 1.2.100.1
Le terme RÉVISION peut désigner
- a product revision (that's how most people use it)
- une révision d'une construction quotidienne particulière (c'est ce que fait MS)
La principale différence entre les deux processus est de savoir si vous souhaitez ou non appliquer des correctifs aux builds CI et donc à quel stade du processus la branche est établie. Cet aspect devient important lorsque vous voulez pouvoir choisir une version particulière à tout moment après que tous les tests ont réussi 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 à l'emploi, en cas de besoin. 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 n'est rien de plus qu'une branche située sous /tags.
Voir également
De la section FAQ à Stratégie de branchement TFS :
Dans quelle branche dois-je réparer le ticket P1 (hotfix)?
Le P1 doit être fixé 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 une autre branche et en déployant les modifications apportées à la production, vous risquez de publier du code semi-fini ou non testé à partir des itérations suivantes.
Maintenant, vous pouvez discuter s'il est 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 s'agit d'un problème fondamental, il doit être ajouté 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 leur documentation MSDN pour la classe Version. Voici la partie pertinente:
major.minor [.build [.revision]]
Les composants sont utilisés par convention comme suit:
Majeur: les assemblages portant le même nom mais différentes versions majeures ne sont pas interchangeables. Un numéro de version supérieur peut indiquer une réécriture majeure d'un produit où la compatibilité descendante ne peut pas être supposée.
Mineur: si le nom et le numéro de version principale sur deux assemblys sont identiques, mais que le numéro de version mineure est différent, cela indique une amélioration significative dans le but d'une compatibilité descendante. Ce numéro de version secondaire plus élevé peut indiquer une version ponctuelle d'un produit ou une nouvelle version entièrement rétrocompatible d'un produit.
Build: une différence de 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 changent.
Révision: les assemblys portant le même nom, les mêmes numéros de version majeure et mineure mais des révisions différentes sont censés ê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é.
Il y a au moins quelques choses différentes que je pourrais imaginer le numéro de build référençant:
Version de contrôle de source qui a été publiée. Par exemple, s'il y a eu une version de la révision # 12345, cela peut être suivi en ayant le numéro de build et s'il est corrigé c'est là que les révisions peuvent augmenter car ce ne sont pas de nouvelles fonctionnalités qui augmenteraient les versions majeures ou mineures et le numéro de build doit être mémorisé au cas où quelqu'un voudrait exécuter à nouveau ce build.
Identifiant du serveur d'intégration continue. Dans ce cas, le serveur CI peut numéroter chaque build qu'il exécute et donc le numéro de build correspond à ce qu'une build réussie obtient 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 en ce qui concerne les nombres sur des bases de code.
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 numéros MAJOR ou MINOR sont modifiés.
La plupart des moteurs d'intégration continue permettent des numéros de génération uniques générés automatiquement.
La révision peut être utilisée pour les correctifs des versions. Disons que 2 équipes travaillent sur un produit.
L'équipe 1 est la principale équipe de développement et produit une compilation nocturne avec le schéma de version 1.0.X.0 suivant, où X est incrémenté. Maintenant qu'ils sont à la version 1.0.50.0, l'équipe 2 prend de temps en temps une version. Disons qu'ils prennent la version de la semaine dernière qui est 1.0.43.0 et commencent à l'utiliser. L'équipe 1 passe à 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 version principale, de sorte que la modification apparaîtra 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 patcher des versions spécifiques.
Permettez-moi de dire comment je le vois et comment l'utiliser ....
Version de ProgramName major.minor.build.revision
major: Pour moi, c'est le projet en cours sur lequel je travaille. Le numéro ne changera pas jusqu'à ce que je démarre un nouveau projet du même nom de programme. Cela signifie que j'écrirai littéralement un nouveau programme du même sexe (exemple: accès v1 - accès v-2 - accès v-3 * tout le même programme mais complètement réécrit).
mineur: cela signifie que j'ajoute des fonctionnalités au projet publié en cours. Par exemple, j'ai peut-être ajouté la possibilité d'imprimer un reçu ou ajouté la possibilité d'importer des photos. Fondamentalement, je veux ajouter des fonctionnalités supplémentaires maintenant et ne pas attendre la prochaine version majeure pour le faire.
build: Ceci que j'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.
révision: Ceci que j'utilise pour indiquer un correctif de bogue dans l'actuel major.minor.build publié - Il y a des occasions où je ne fais pas progresser le projet en cours et un bogue survient. Ce bogue doit être corrigé et publié. Cela signifie simplement que je corrige ce que j'ai déjà publié pour qu'il fonctionne correctement. Je l'utiliserais également si je travaille sur une nouvelle version, un nouvel ajout ou que je démarre une nouvelle version majeure. La version publiée doit évidemment être corrigée pendant que nous attendons la prochaine version majeure, mineure ou de build.
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 donnera à quelqu'un une meilleure compréhension de la façon dont ce type de version fonctionnerait (ou devrait) fonctionner. Pour moi, c'est la seule définition et pratique qui a un sens réel lors de l'utilisation de ce type de versioning.
Je n'ai vu qu'un numéro de build comme le dernier numéro de l'ID de version. Je ne sais pas comment vous auriez trouvé une révision d'un numéro de build. Je suppose que si vous avez changé certaines des ressources non construites (icônes, script DB, etc.), peut-être, mais la plupart des projets sur lesquels j'ai travaillé récemment ont également tout cela sous contrôle de version, donc le processus de construction les reprend quand faire l'installateur/release. J'aime les numéros de build horodatés, mais pas tout à fait comme @David le décrit (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 build de notre serveur d'intégration continue (Jenkins pour nous). Cela nous donne plusieurs avantages - le fait d'avoir le numéro de version défini par notre serveur CI supprime une étape manuelle qui pourrait autrement être accidentellement manquée; il est facile de vérifier qu'un développeur n'a pas fait une version effrontée de son PC de développement (ce qui entraînerait que ces chiffres soient nuls); et cela nous permet de lier n'importe quel logiciel à la fois au code à partir duquel il a été généré et le travail CI qui l'a construit, simplement en regardant le numéro de version - que nous trouvons parfois très utile.
C'est ce que vous voulez que ce soit. J'ai tendance à utiliser year.month.day.hhmm pour ma révision majeure. Si j'en produis plus d'une par minute, quelque chose ne va pas. vous pouvez simplement utiliser un incrément simple, ou j'ai vu des générateurs élaborés pour eux. Qu'est-ce que vous voulez que ce soit. Ce qu'ils doivent faire, c'est que vous arriviez à la source utilisée pour créer cette sortie, donc tout ce qui vous permet de le faire.
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 n'utiliseront que 1234 car la partie 2 ne change pas fréquemment.
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 réellement la build. TeamCity crée un nouveau fichier AssemblyInfo avec les bons # pendant le processus de construction.