Quelques remarques :
1 il faudrait mettre à jour http://doc.spip.org/plugin-xml
2 il faut mettre à jour avec le nouveau format tous les plugins qui ont une
dépendance envers spip 1.9.3
3 il est possible d'ajouter à tous les plugins de la zone
<necessite id='SPIP' version='[1.9;]' />
4 il faut que $spip_version_branche soit au format suggéré dans http://trac.rezo.net/trac/spip/ticket/687 , avec en plus au moins trois sectinos, sinon la version 2 12000 serait considérée plus récente que
la 2.1 13000
5 il est possible d'incrémenter $spip_version_code très souvent
6 mettre $spip_version_branche='2.1.0 beta 2"; me semble suffisant
pour gérer les branches de développement
7 personne ne voit de défaut dans le nouveau système ?
Je peux faire 1, 2 (pour la zone, et sans indiquer une version de spip
très précise), 3.
Cette nouvelle habitude de systématiquement s'assoir sur la compatibilité ascendante, qui plus est pour des petits détails, est vraiment une mauvaise habitude.
À la rigueur, en attendant la 2, je veux bien. Mais à partir de la 2, il faudra vraiment décréter les méthodes comme pérennes.
Il n'y a pas moyen de conserver une compat ascendante ?
J'abonde dans le sens de Fil.
Cette nouvelle habitude de systématiquement s'assoir sur la compatibilité ascendante, qui plus est pour des petits détails, est vraiment une mauvaise habitude.
C'est corrigé en [11988], c'etait une erreur de ma part sur le numero de branche :
on utilisait autrefois des numeros du type 1.9253 sans point separant la virgule,
et j'ai reintroduit 1.9.3.xxx avec des points, ce qui fait foirer la comparaison.
Le changement de format ne pouvait se faire sans casse qu'en changeant le premier chiffre, donc en passant à 2.0.0, ce que j'ai fait.
À la rigueur, en attendant la 2, je veux bien. Mais à partir de la 2, il faudra vraiment décréter les méthodes comme pérennes.
Oui pour ce qui a pu être formalisé, mais tout ce qui ne l'a pas encore été et repose encore sur de l'ancien code qui n'avait pas été pensé pour cela subira encore forcément de la casse.
Mais je suis d'accord que ce ne doit pas être une raison et qu'à chaque fois que cela est possible, il faut eviter de casser la compatibilité.
Cédric