Quelle est la bonne façon de gérer la version d'assemblage?

Question

Je suis impatient de mettre en place un build quotidien pour un projet à venir.

Mais avant de faire cela, je dois savoir comment mettre à jour correctement un assemblage.

J'ai les préoccupations suivantes:

• Chaque assemblage doit-il avoir un numéro de version indépendant ou doit-il partager la même version?
• Devrais-je utiliser une version * pour la construction et la révision?
• La révision est-elle pertinente pour la construction quotidienne?

Answer 1

Nous imprimons le même numéro de version sur tous les assemblages de nos produits en procédant comme suit:

• Liez tous les assemblages à un AssemblyInfoCommon.cs contenant le numéro de version: voir ici pour un exemple.

• Générez le fichier AssemblyInfoCommon.cs dans le cadre de la construction. en utilisant (dans notre cas) la tâche NAnt asminfo, Cruise Control .NET et l’étiqueteuse de révision SVN

Dans notre cas, nous n'utilisons pas la version *. Toutes les versions déployées sont construites sur le serveur de compilation. Nous ne nous inquiétons pas du numéro de version sur nos ordinateurs de bureau.

Answer 2

La réponse dépend vraiment de ce que vous essayez d'accomplir avec les numéros de version de l'assemblage. Si vous effectuez un déploiement ClickOnce et souhaitez effectuer des téléchargements indépendants d'assemblys mis à jour, vous devez attribuer une version indépendante à chaque assemblage. Dans le cas contraire, il est souvent agréable de faire correspondre les versions d'assemblages au numéro de version du logiciel. Dans des scénarios plus complexes, vous aurez peut-être besoin d'une autre stratégie.

Un schéma que j'avais utilisé dans une société antérieure était major.minor.revision.build. Ainsi, dans la version 1.0 du produit, la version de l'assemblage et la version du fichier d'assemblage de chaque assemblage étaient 1.0.0.1129 (par exemple). Cela a facilité la mise en correspondance des assemblys faisant partie de quelle version du logiciel, jusqu'au numéro de build. Pour ce faire, nous avons utilisé une recherche de pré-compilation et un remplacement dans chaque fichier AssemblyInfo.cs pour remplacer un jeton par les numéros de version fournis par notre processus de génération automatisé.

Answer 3

Ainsi, chaque assemblage doit avoir la même version, qui est généralement une combinaison de la version de la version, à savoir 3.4 + du numéro de version, qui est une séquence représentant le nombre de fois que la version a été compilée sur le serveur de génération. La révision est pertinente car elle indique le nombre de générations que vous avez créées pour cette version. Vous pouvez vraiment le faire de deux manières. La première consiste à dire que si vous avez planifié une version 3.4, puis que vous commencez à travailler sur cette version, il s'agit de votre numéro de version principal et votre numéro de version mineur s'incrémente avec la construction. Une autre façon de procéder consiste à contrôler étroitement les versions de compilation, car lorsque vous êtes prêt à exécuter votre publication vers QA / Regression, vous définissez votre version principale à 3.4 et vous laissez votre numéro de version mineure sur 0. Vous gardez le contrôle strict de cette façon. jusqu'à ce que vous libériez. De cette façon, vous pouvez contrôler la numérotation de votre service pack par le biais du numéro de version mineure. J'espère que cela vous aidera.

Answer 4

Je conviens normalement que tous les assemblys doivent avoir le même numéro de version; Cependant, je voudrais faire une mise en garde à cela. Si l'un des assemblys est utilisé ailleurs que dans ce projet ou s'il est considéré comme son propre projet, il doit avoir son propre numéro de version. Il devrait également probablement être déplacé de cette solution vers la sienne. La seule raison pour laquelle je mentionne cela est que j’ai souvent vu des personnes utiliser un assemblage utilisé ailleurs, mais principalement à un endroit et essayer de garder la version droite. C'est une mauvaise idée de faire ça. Je pense que le principe de responsabilité unique s’applique également au niveau de la solution / du projet.

En ce qui concerne la numérotation, je suis d’accord avec Guy Starbuck (major.minor.revision.build). C'est comme ça que je l'ai toujours fait et ça a toujours bien fonctionné.

Answer 5

Nous avons une grande application (des centaines d'assemblages) avec des versions fréquentes (environ une par mois). Nous avons opté pour l'option "Donner à chaque assemblée la même version". mais c’est une source constante de frustration pour moi que les assemblages pour une version soient complètement incompatibles avec ceux d’autre, malgré le fait que les interfaces de ces ordinateurs changent rarement (si jamais).

Si tel est votre cas, vous pouvez tirer parti du versionnage des assemblages séparément. Chaque fois que vous mettez à jour votre assemblage, vous ne pouvez incrémenter le numéro de version que dans les cas où vous souhaitez réellement rompre la liaison de l'assemblage (par exemple, si l'interface change, ou les modifications sont importantes car vous souhaitez éviter que quelqu'un n'utilise accidentellement la version précédente).