Comment faites-vous la numérotation des versions dans un projet agile?

Question

Actuellement, nous utilisons le système de numérotation de version suivante pour notre projet C# WinForms:...

"majeure" "mineure" "Numéro Iteration" "Numéro de build dans ce Iteration"

Nous voulait être en mesure d'identifier le numéro d'itération et le numéro de construction dans cette itération juste en regardant le numéro de version.

Dans le passé, nous avions fait quelque chose comme: "Major Release". "Minor Release". "Numéro de build séquentiel à partir de 1.0". Par exemple, "4.0.648" signifierait qu'il y avait 648 builds depuis la version 1.0 - mais cette information est assez inutile et anecdotique, c'est pourquoi nous avons changé pour refléter les itérations et les construire au sein des itérations. Par conséquent, compte tenu de cette nouvelle numérotation de version agile, nous avons maintenant le problème lorsqu'un groupe de produits différent souhaiterait modifier son itération pour notre projet. Dans ce cas, le numéro de version n'aurait pas de sens, car leurs numéros d'itération et de construction ne correspondent pas. Par exemple, la dernière version de mon projet était 1.0.5.1 indiquant la première version de l'itération 5. Maintenant, cet autre projet dans sa troisième itération voudrait apporter des modifications à mon projet et reconstruire.

Comment est-ce que je devrais faire face à cette situation? Comment faites-vous la numérotation des versions dans votre projet agile?

Answer 1

Je surveille l'itération des projets agiles, pas l'itération des projets logiciels. Si un projet de démarrage tardif rejoint un autre projet, il initiera donc l'itération actuelle du projet agile, et il n'y aura pas de désalignement.

Un projet technique en dehors du domaine du projet agile ne doit pas pouvoir interagir avec un projet dans le domaine. Ce serait une défaillance de PM du processus et devrait être éliminée dans tous les cas où une base de code partagée est utilisée avec branchement, à patcher dans le tronc comme une étape de nettoyage après l'achèvement du projet.

Answer 2

Je préfère Major.Minor.Build.Revision où Build - le nombre de communiqués publics, Revision - une révision de la version source système

Answer 3

Je préfère séparer le processus de construction et de la libération du processus de développement de l'équipe, donc j'ajouterais à peine le la itération, sprint ou similaire à la version. Votre cas est un bel exemple sur la façon dont les deux choses mélangées ne sont pas faciles à gérer. Et si vous changez de méthodologie au milieu du projet (quelle qu'en soit la raison)?

En réponse à votre question, nous utilisons Scrum depuis deux ans et notre format de version est le classique Major.Minor.Upgrade.Build (nous utilisons uniquement Upgrade sur les corrections de bugs). En fin de compte, il n'est pas obligatoire d'utiliser le numéro de build, car vous n'en avez besoin que pour désambiguïser différents paquets de la même version, mais vous pouvez utiliser un autre symbole qui représente une sorte de version privée.

Answer 4

Personnellement, je pense que la version de version que j'ai aimé le mieux est de faire disparaître l'ensemble des choses major.minor. Je pense que cela n'est vraiment faisable que pour les applications internes, mais pour cela, ça rend la vie beaucoup plus facile.

Généralement, si vous développez des applications orientées vers l'intérieur, j'ai remarqué que l'entreprise ne se soucie jamais réellement de la version majeure/mineure utilisée. Au lieu de cela, ils ont tendance à vouloir savoir a) quand est la prochaine version et b) ce qui va être dans ou hors - et c'est à peu près tout. Essayer de garder le fait que vous travaillez sur FOO-4.34.0.1-a et BAR-3.19.4.1 lorsque personne ne se soucie seulement de compliquer la communication.Dans un groupe précédent, nous n'avions pas vraiment de versions majeures autres que le lancement d'un projet. Chaque sortie était aussi 'majeure' que la précédente. Par conséquent, je pense qu'ils ont fait la chose sensée et au lieu de cela communiqué à l'entreprise comme PROJECT_RELEASENUM. Le numéro de version a été incrémenté de '1' à chaque fois que nous avons publié une version, avec des correctifs comme PROJECT_RELEASENUM_PATCHNUM, qui a également été incrémenté de '1'. Il fonctionne bien avec la notion que le développement est fait comme une série continue de sprints jusqu'à ce que l'entreprise ait toutes les fonctionnalités dont ils ont besoin (ce qui en pratique ne se produit jamais - il y a toujours plus de choses qu'ils veulent). Les entrepreneurs le comprenaient, les développeurs pouvaient le communiquer et se prêtaient naturellement au modèle de développement continu que nous avions.