Yo,
Des fois on commit directement en stable parce que ça nous semble un
truc bénin, et avec la relecture de quelqu'un d'autre il s'avère que ça
l'est pas tant que ça. Le dernier exemple est le commit sur
_RENOUVELLE_ALEA, mais ces derniers mois c'est arrivé plusieurs fois
(je l'ai fait aussi il y a quelques mois, une histoire d'URLs propres
je crois).Du coup, même pour des commits a priori bénins, je propose qu'on
formalise quelques petites règles par rapport à ça, si ça vous dit :- on fait d'abord les commits dans la branche de dev (master / trunk)
En pratique, c'est le genre de bug qu'on découvre sur un site en production.
Donc concrètement :
- je patche pour voir ce que ça donne
- quand la correction semble OK je la commit
- ensuite je la reporte.
Concrètement il est bien plus facile de commit directement sur la branche ou le bug a été découvert et résolu que de générer un patch, puis de le rapatrier sur le site test de dev puis de le commit, puis de le reporter, puis de re-up le site concerné qui présentait le bug pour le resynchroniser.
Je suis d'accord que dans un monde idéal on ferait ça d'abord sur la branche dev puis report sur les branches stables lorsque tout le monde est d'accord.
Peut-être est-ce là qu'on pourrait bénéficier de la puissance de git et de ses branches, en créant une branche bugfix correspondant a chaque branche stable. Ainsi dans ce genre de cas on ferait juste
git checkout bugfix-2.1
git commit
ce qui permettrait d'envoyer le commit sans impacter la branche stable.
Ensuite on l'envoi dans la branche dev, puis dans les branches stables quand tout le monde est OK.
- si c'est bon, on reporte dans les branches stables (si ça a du sens).
- exception: on commit directement dans une branche stable uniquement
pour une modif non-applicable à la branche de dev (par exemple pour
cause de gros changement dans le code depuis lors), mais applicable
dans les branches stables, en essayant de s'en tenir à des modifs
"safe" ou très importantes.Et ajouter que dans tous les cas, quand on commit direct en stable, on
le justifie dans le message de commit.
Oui, mais bon, on va pas faire des mots d'excuse du genre "ah ben là j'etais sur mon serveur de prod"
En parallèle à ça, je voudrais proposer qu'on essaie de releaser plus
souvent. Je propose ça car je sens que souvent on a envie de committer
en stable parce qu'on a hâte de voir la modif en question dans une
release.
Oui, c'est un risque potentiel. Releaser plus souvent n'est pas difficile, mais ça implique plus de travail de documentation, de test, de revue des tickets, etc.. à de chaque release.
Donc il faut sans doute trouver le bon compromis.
Cédric
(je repasse sur spip-dev)
