Tout dépend du contexte: à quelle fréquence publiez-vous et ce qui se trouve dans une version.
Voici un peu une étude de cas que j'avais avec mon ancien travail, en utilisant la méthode B (nous l'avons appelé branche par objectif ).
Pour mettre l'histoire en contexte,
- Une version consistait en de nouvelles fonctionnalités dans notre logiciel: nouveaux modes de jeu, nouvelles fonctionnalités, nouvelles options de configuration.
- Le cycle de sortie a été assez long: nos clients étaient des universités qui s'en tiendraient à un ensemble de fonctionnalités pendant généralement un an.
Le développement principal a été effectué dans le tronc jusqu'à ce que nous atteignions un état complet pour une certaine version. À ce stade, nous créerions une branche, par exemple projectname-janvier2012 et ferions nos tests de qualité et corrigions les bogues dans cette même branche. Une fois que nous étions prêts pour une version publique, nous étiquetions le code dans cette branche et le publions.
Cependant, le développement de la version ne s'est pas terminé à cette balise. Inévitablement, nous avons eu des clients qui ont trouvé des bogues ou de petits problèmes avec la version. Donc, dans ce cas, tout ce que nous devons faire est de revenir à cette branche, de corriger le code et de créer une nouvelle version balisée de la branche de janvier 2012 à publier, et de fusionner les correctifs dans le tronc.
Dans notre cas, cette approche était favorable car certains utilisateurs préféraient rester avec des versions plus anciennes avec un ensemble limité de fonctionnalités, ou tout simplement parce que le coût du déploiement sur leur infrastructure d'une toute nouvelle version plutôt que d'un correctif a causé certains problèmes.
Les questions que vous devez vous poser sont donc:
- À quelle fréquence dois-je libérer?
- Mes versions seront-elles 100% rétrocompatibles?
- Mes clients seront-ils d'accord avec une mise à niveau complète pour corriger les bugs?
Si vous sortez souvent, cela ne vaut peut-être pas la peine d'avoir des branches pour chacun d'eux. Cependant, si votre cycle de publication est assez long comme mon ancien cas d'utilisation, et que le déploiement, la compatibilité descendante et les clients qui s'accrochent aux anciennes versions peuvent être des risques, l'option B vous épargnera certainement beaucoup de douleur, rendra les choses beaucoup plus faciles à prendre en charge vos clients au moindre coût lié à l'encombrement des succursales.