La gestion des versions est quelque chose que je suis très passionné et ont passé un long moment à essayer de trouver un facile d'utiliser le système de gestion de versions. À partir de ce que vous avez déjà dit dans votre question, il est clair que vous avez entendu un point important, l'assemblée des numéros de version ne sont pas synonymes de la version du produit. L'un est techniquement poussé l'autre est entraînée par l'entreprise.
Ce qui suit suppose que vous utilisez une certaine forme de contrôle de source et un serveur de build. Pour le contexte, nous utilisons TeamCity et de la Subversion/GIT. TeamCity est gratuit pour un petit (10) nombre de projets et est un très bon serveur de build, mais il en existe d'autres dont certains sont totalement gratuit.
Ce qu'est un numéro de version de moyens
Quelle version de moyens pour une personne peut signifier quelque chose de différent à l'autre, la structure générale est majeur, mineur, macro, micro. La façon dont je regarde un numéro de version est de le décomposer en deux parties. La première moitié décrit la version principale (Major) et toutes les mises à jour de clés (Mineur). La seconde moitié indique quand il a été construit et ce que le code source de la version. Les numéros de Version aussi signifier des choses différentes en fonction du contexte, est-il une API, Web App, etc.
Major.Minor.Build.Revision
-
Revision C'est le nombre de prises de contrôle de code source pour identifier ce qui
a été effectivement construit.
-
Build C'est un nombre sans cesse croissant qui peut être utilisé pour trouver un
particulier de construire sur le serveur de build.
C'est une importation nombre, parce que la
serveur de génération peut avoir construit de la même
source deux fois avec un ensemble différent de
les paramètres. En utilisant le numéro de build dans
conjointement avec le numéro de la source
vous permet d'identifier ce qui a été construit
et comment le faire.
-
Minor Cela ne devrait changer que quand il y a un changement significatif de
l'interface publique. E. g si c'est un
API serait de consommer de code encore
en mesure de compiler. Ce nombre doit être remis à zéro lorsque le nombre important de changements.
-
Major indique quelle version de la
produit que vous êtes sur. Par exemple, le
Les grands de tous les VisualStudio 2008
les assemblées 9 et VisualStudio 2010
10.
L'exception à la règle
Il y a toujours des exceptions à la règle, et vous devrez vous adapter comme vous les rencontrez. Mon approche est basée sur l'utilisation de subversion, mais récemment, j'ai déménagé à GIT. Contrôle de code Source comme subversion et de source sûre que l'utilisation d'un référentiel central ont un nombre qui peut être utilisé pour identifier un ensemble particulier de sources à partir d'un moment donné. Ce n'est pas le cas pour un système distribué de contrôle à la source tel que GIT. Parce que GIT utilise les référentiels distribués qui sont sur chaque machine de développement il n'y a pas d'auto-incrémenter le nombre que vous pouvez utiliser, il ya un hack qui utilise le nombre de check-ins, mais qu'il est laid. Parce que de ce que j'avais à faire évoluer mon approche.
Major.Minor.Macro.Build
Le numéro de révision est maintenant révolu, de construire s'est déplacé à l'endroit où la révision et de la Macro a été inséré. Vous pouvez utiliser la macro comment vous voyez l'ajustement, mais la plupart du temps je le laisser seul. Parce que nous utilisons TeamCity les informations perdues à partir du numéro de révision peut être trouvé dans la construire, il ne signifie pas qu'il ya un processus en deux étapes, mais nous n'avons rien perdu et est un compromis acceptable.
Ce jeu
La première chose à comprendre est que la Version de l'Assembly, la Version du Fichier et la Version du Produit n'ont pas à correspondre. Je ne suis pas plaider ayant différents ensembles de nombres, mais il rend la vie beaucoup plus facile quand apporter de petits changements à une assemblée qui n'a pas d'effet interfaces publiques que vous n'êtes pas obligé de recompiler dépendante des assemblées. La façon dont je traite ce problème est de définir la les numéros Majeur et Mineur dans la Version de l'Assembly, mais afin de définir toutes les valeurs dans le Fichier Version. Par exemple:
- 1.2.0.0 (AssemblyVersion)
- 1.2.3.4 (FileVersion)
Cela vous donne la possibilité de déployer des correctifs qui ne cassera pas le code existant, car l'assemblée versions ne sont pas identiques mais qui vous permettent de voir la révision/mise en place d'un assemblage en regardant son numéro de version du fichier. C'est une approche commune et peut être vu sur l'open source, assemblées, si vous regardez les détails d'assemblage.
Vous comme le chef d'Équipe devra être responsable pour incrémenter le numéro mineur quand jamais une modification de rupture est nécessaire. Une solution pour le déploiement d'un changement nécessaire à une interface, mais pas de rupture de code précédent est de marquer l'actuel obsolète et création d'une nouvelle interface. Cela signifie que le code existant est averti que la méthode est obsolète et peut être supprimé à tout moment, mais ne vous obligent pas à tout casser immédiatement. Vous pouvez ensuite retirer la méthode obsolète quand tout a été migré.
Comment câbler ensemble
Vous pourriez faire tous les ci-dessus manuellement, mais il serait très coûteuse en temps, les suivants est comment nous automatiser le processus. Chaque étape est praticable.
- Supprimer l'
AssemblyVersion et AssemblyFileVersion les attributs de tous les le projet AssemblyInfo.cs fichiers.
- Créer une assemblée commune de fichier info (appel il VersionInfo.cs) et l'ajouter comme un élément lié à l'ensemble de vos projets.
- Ajouter
AssemblyVersion et AssemblyFileVersion attributs de la version avec les valeurs de "0.0.0.0".
- Créer un projet MsBuild que la génération de votre fichier de solution.
- Ajouter une tâche préalable à la construction que les mises à jour de la VersionInfo.cs. Il y a un certain nombre de l'open source MsBuild bibliothèques qui comprennent une AssemblyInfo tâche qui peut définir le numéro de version. Il suffit de le régler à un nombre arbitraire et de test.
- Ajouter un groupe de propriétés contenant une propriété pour chacun des segments du numéro de build. C'est là que vous définissez la majeure et la mineure. La construction et le numéro de révision devrait être adopté en tant qu'arguments.
Avec subversion:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
J'espère avoir été clair, mais il est beaucoup impliqué. Merci de poser toutes les questions. Je vais utiliser les commentaires pour en mettre un plus concis post de blog ensemble.
