Jusqu'à maintenant on ouvre une branche 2.n qu'à partir du moment où la
release 2.n est publiée et passe en maintenance (2.n.1, 2.n.2, …).
La default est (jusqu'à maintenant) la prochaine release 2.n+1

Je ne pense pas que créer une branche 2.6 immédiatement fera que les merges
seront plus simples, ça dépend de toute façon des commits qui sont faits
d'un côté ou de l'autre.
De plus, aujourd'hui on a deux branches actives (default, 2.5) — j'ignore
la sexy pour les besoins de mes propos — et en créer une de plus (2.6)
rajouterait de la complexité pour maintenir les trois branches synchros.

Ensuite savoir où commiter dépend de ce qui est commité. Un ticket fermé
sur la 2.5.3 devrait l'être sur la branche 2.5, histoire d'être testé sur
cette branche (avec report ultérieur sur la branche default une fois que
c'est fait). Les tickets affectés à la 2.6 devraient l'être sur la branche
default.

Évidemment on peut discuter de tout ça.


Le 14 août 2013 10:09, Nicolas <[email protected]> a écrit :

> Le 14 août 2013 10:02, Franck Paul <[email protected]> a écrit
> :
>
> > Un truc auquel faire attention : bien s'assurer que la branche choisie
> est
> > la bonne pour le(s) commit(s) et le PR
> >
> >
> On ne commite pas sur default ?
>
> J'aimerais qu'on en parle à une prochaine réunion. Je trouve qu'on tire les
> nouvelles branches trot tôt. Enfin ce n'est que mon avis d'humble
> développeur. Quand on tire une branche on ne fait plus que des corrections
> de bug dessus. Ce qu'on appelle default (ou master) aujourd'hui est pour
> toit la future 2.6 et je ne trouve pas ça logique. Soit c'est une 2.6 et on
> créé la branche 2.6 et default récupère tous les commit avec des merge sur
> la 2.6 s'il le faut, soit c'est le tronc et on commite tout dessus.
>
> Quand une branche vit trop longtemps, le merge est de plus en plus
> compliqué et de moins certain.
>
> Nicolas
> --
> Dev mailing list - [email protected] -
> http://ml.dotclear.org/listinfo/dev
>



-- 
Franck
-- 
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev

Répondre à