On est dans de l'exploratoire, non testé, qu'on est même pas sur de garder.
Testons dans la branche de dev si tu veux, mais pas dans cette branche.
Tu oublies que les fichiers de langues ont été modifiés dans cette branche, maintenant il faut se poser la question des inconvénients du retour en arrière aussi pour eux.
Le plugin ortho est utilisé par 0.1% des sites, et le seul désagrément est d'avoir un descriptif cassé pour ceux qui le mettront à jour.
Les bugs que l'on découvrira surement après la release auront bien plus d'impact, tout cela, je le répète, pour zéro intérêt fonctionnel dans cette branche (puisque de toutes façons les nouveaux formats de paquet.xml ne seront pas lus par cette branche).
Esnuite pas de panique pour le code PHP, il n'est mis en branle que par un test dans plugin_propre, il suffit de le remplacer par "if (false)" ou commenter les 2 lignes si vraiment on y tient.
Oui, on a bien vu le résultat. Le bug est toujours là ou on l'attends pas, et on sait pertinement qu'à chaque fois qu'on touche du code on introduit un nombre de bugs directement lié au nombre de lignes modifiées.
Enfin l'expérience vient de montrer que même en soumettant à la discussion pendant deux semaines ce que deux membres de l'équipe souhaitent faire, tous les tenants et aboutissants n'aparaissent qu'au moment de la première intervention dans le code.
Oui, mais ça aurait marché pareil dans la branche dev sans casser la branche stable. Ou dans un plugin de travail pour tester le concept. Comme on le fait sur textwheel, job_queue, SVP ....
Casser la branche stable pour des "expérimentations" n'est jamais défendable.
Alors finissons de voir si la piste est tenable, et on décidera ensuite si le retour en arrière n'est vraiment pas plus problématique que de continuer à avancer.
Je propose de brancher en 2.2, repousser le tronc en 2.3 et revert sur la 2.1.
Cédric
