Le 14 août 2013 10:34, Nicolas <[email protected]> a écrit : > 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. >
Euh, c'est une façon de voir les choses, mais pas la seule :-p > > > 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. > Oui, majeures (dans le sens : modifie des fonctionnalités, peut casser des choses, …). > > > > 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. > Non, jusqu'à maintenant les branches 2.n reçoivent aussi des modifications mineures (comprendre : petite fonctionnalités qui ne cassent rien) > > > > > > 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. > > L'idée retenue (récemment) : corriger ce qui doit l'être sur la branche 2.5, tester cette branche et report sur default ensuite. (en suivant l'affectation des tickets bien sûr) > > > > 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. > > C'est là où je dis qu'il va se poser des problèmes car on va avoir des difficultés à extraire une partie seulement des commits faits sur default pour générer la 2.6. Dans mon idée il vaut mieux faire des PR (via des branches annexes si besoin) et les fusionner le moment venu. > > > > É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. > > Oui c'est à mettre dans la doc, une fois que le workflow sera figé, tu as raison. -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
