Contrôle de source: quelle numérotation de version doit être utilisée pour les branches?

Question

Si une branche est créée dans le contrôle de la source, quel numéro de version devrait être utilisé s'il y a une version du code ramifié?

par ex. Si le dernier numéro de version était v1.2.8 et qu'une branche est créée, quels devraient être les numéros de version suivants de la branche et du tronc principal?

Answer 1

Il dépend de ce que la branche est pour (quel effort de développement, il isoler, comme décrit dans « When should you branch »)

Par exemple, pour une solution qui n'ajoute une nouvelle fonctionnalité, il pourrait être v1.2.9.
Mais en réalité, les politiques de numéro de version sont:

• très diverses (voir cette list for instance)
• can be a bit crazy at time
• ne doit pas être mélangé avec internal technical revision number
• peut être doublé par un commercial naming strategy

La chose importante à retenir est qu'une étiquette comme vx.y.z peut être générée ed sur toute branche. Il marque simplement un point stable dans le cycle de vie du développement.

Answer 2

Dans notre projet, nous suivons la stratégie de branche de publication unique: la version sera toujours exécutée sur la branche de publication. Il peut y avoir plusieurs branches de développement/fonctionnalité/correction de bogues, mais nous ne libérons jamais le produit de ces branches. Ils seront d'abord fusionnés dans la branche Release et libérés de la branche Release.

Sur une branche non relâchée, la version SNAPSHOT est toujours utilisée (nous utilisons Maven) et le nom de la version est le nom de la branche. Par exemple sur une branche qui nomme featureX, la version est featureX-SNAPSHOT. A la libération, la version numérique de la branche est utilisée. Le numéro de version sera ajouté dans la nouvelle version. De cette façon, nous ne serons pas dérangés par le numéro de version à utiliser dans une branche non relâchée.