Le 14 août 2013 10:18, Franck Paul <[email protected]> a écrit :
> 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 > > Que l'on se dise que l'on prépare la prochaine version ne me choque pas mais defautl devrait recevoir tous les commit. > 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. > Des commits sur default sont des évolutions. > 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. > Les branches nommées 2.n ne reçoivent que des corrections de bugs, aucune évolution si minime soit elle. Donc pas difficile à merger. > > 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). C'est là où ça me gêne. Si on corrige un bug sur une version publique (2.5.3) alors on corrige sur la branche 2.5 ce qui donnera lieu à une 2.5.4. Mais on doit reporter sur default tout de suite ou au moins tester tout de suite sinon c'est la regression presque assurée. > Les tickets affectés à la 2.6 devraient l'être sur la branche > default. > Oui évidemment mais pas uniquement. Si un commit ne casse rien, il devrait être aussi sur default même si le ticket (il y a forcément un ticket) n'était pas attaché à default. Par exemple le nettoyage que Bernard est en train de faire devrait être être reporté sur default. Les tests unitaires fonctionnels devrait être sur default... On n'est pas en phase de freeze donc tout peut se retrouver sur default. Evidemment les deux exemples que j'ai donné n'ont absolument aucune raison de se retrouver sur les autres branches. > > Évidemment on peut discuter de tout ça. > On n'est déjà un peu en train de le faire ! :-) On peut ouvrir une discussion à part si tu préfères. Et ce serait pas mal de le mettre quelque part dans la doc (si ce n'est pas déjà fait) pour les contributeurs. > > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
