il faudrait peut-être juste arrêter la pratique d'ajouter des fonctions mineures dans les 2.x.x, et sortir plus souvent des 2.x ?
2013/8/14 Franck Paul <[email protected]> > Jusqu'à maintenant on gère (assez bien) la présence des deux branches, 2.5 > et default. Cela dit nous n'étions pas une foultitude à commiter non plus. > > On peut modifier notre "workflow", ça ne me pose pas plus de souci que ça, > à condition que la gestion des merge de branche n'en soit pas (trop) > compliquée. > > Quoi qu'il en soit, je préfèrerais que xave, actuellement de l'autre côté > de la mare, puisse participer activement à toute décision qui sera prise à > ce sujet, donc plutôt à la rentrée (scolaire). > > > Le 14 août 2013 10:56, Nicolas <[email protected]> a écrit : > > > Le 14 août 2013 10:40, Julien Wajsberg <[email protected]> a écrit : > > > > > 2013/8/14 Nicolas <[email protected]> > > > > > > > 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. > > > > > > > > > > > > > c'est pas ce qui avait déjà été convenu il y a genre 2 jours ? > > > > > > > Je me demandais mais c'est pour être sûr. > > > > > > > > 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. > > > > > > > > > amha il devrait être fait _que_ sur default, aucune raison de le mettre > > sur > > > la branche en maintenance. > > > > > > > On est d'accord. Je parlais surtout du fait de ne pas créer une branche > qui > > vit pendant des mois à côté de default qui demande un gros effort à > > maintenir à jour et qui demandera un gros effort à merger si jamais on > > réussit à la merger un jour. Par expérience quand une branche vit plus de > > quelques semaines dans son coin elle n'est jamais mergée. > > > > Nicolas > > -- > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
