À l'époque de SVN, les développeurs faisaient ce travail à la main, avec 3 sous dossiers principaux ( dans les projets que j'ai pu voir en fouillant sans contribuer ):
trunk
branch
tag
Chacun de ces dossiers contenait un copier/coller des sources.
Cette façon de travailler à été automatisée—et nettoyée—par git ( et par mercurial j'imagine? ): maintenant, trunk est une branche comme les autres, et l'on tague les commit.
La problématique que tu décris permets d'utiliser ça assez facilement, et d'ailleurs pas mal de projets libres utilisent cette méthodo:
master, ou stable, pour les bug fixes ( une fois la première stable atteinte, naturellement )
experimental, ou devel, peu importe le nom, pour la future version stable
une branche par fonctionnalité ou tâche à effectuer, que l'on merge dans experimental quand ça semble marcher.
Puis les tags sont apposés sur des commits précis d'une branche pour définir l'état de la branche au moment de ce commit: numéro de version, release candidate, etc.
# les branches.
Posté par freem . En réponse au message Gestionnaire de version : organisation et distribution. Évalué à 3.
À l'époque de SVN, les développeurs faisaient ce travail à la main, avec 3 sous dossiers principaux ( dans les projets que j'ai pu voir en fouillant sans contribuer ):
Chacun de ces dossiers contenait un copier/coller des sources.
Cette façon de travailler à été automatisée—et nettoyée—par git ( et par mercurial j'imagine? ): maintenant, trunk est une branche comme les autres, et l'on tague les commit.
La problématique que tu décris permets d'utiliser ça assez facilement, et d'ailleurs pas mal de projets libres utilisent cette méthodo:
Puis les tags sont apposés sur des commits précis d'une branche pour définir l'état de la branche au moment de ce commit: numéro de version, release candidate, etc.