[addon] versionning compatibilité

[remrem]

Je vois sans doute loin, mais j'essaie d'anticiper...

Ne devrait-on pas prévoir un système de versioning pour assurer la compatibilité des addons avec les éventuelles évolution du système d'addon ?

Actuellement, les addons sont développés avec un système que l'on est encore occupé à développer, mais si dans quelques temps, ce système doit changer (bug, évolution, ajout/suppression de hook...) quid de la compatibilité avec les plugins actuel, comment assurer un minimum que les plugins qui ne sont plus à jour "casse/bloque" les process du core ?

[BoboTiG]

J'y avais pensé aussi, et tu fais bien d'en parler maintenant. As-tu une idée d'implémentation ? Si non, je propose celle utilisée par Prestashop :

# Dans les infos de l'addons
'versions_compliancy' => array('min' => '3.7', 'max' => BLOGOTEXT_VERSION),

Sachant que le max peut-être :

• 4.2
• 3.7.9
• BLOGOTEXT_VERSION quand il n'y a pas vraiment de version max

[remrem]

J'ai eu peu de mal à suivre, mais ok, en gros côté addon : $GLOBALS['addons'][]['versions_compliancy'] => '3.7' et côté blogotext, on check avec nos règles min/max.

C'est bien ça ?

[BoboTiG]

Je dirai plutôt :

// version 3.7 seulement
$GLOBALS['addons'][]['versions_compliancy'] =>array('min' => '3.7', 'max' => '3.7.999'),  

// ou une version 3.7 spécifique
$GLOBALS['addons'][]['versions_compliancy'] =>array('min' => '3.7', 'max' => '3.7.3'),  

// à partir de a 3.7, pas de version max
$GLOBALS['addons'][]['versions_compliancy'] =>array('min' => '3.7'),

La clef min est obligatoire. La clef max, si absente, vaudra BLOGOTEXT_VERSION.

Et du côté de BlogoText, oui, on effectue les comparaisons. Si un module ne peut pas fonctionner avec la version actuelle :

• du côté admin, on ne le liste pas, mais on affiche une erreur spécifiant la non compatibilité avec la version actuelle (tout en affichant les versions min et max pour que l'utilisateur en sache plus)
• il est supprimé de $GLOBALS['addons'] ;

[remrem]

Le problème c'est qu'avec ce système, le mec qui nous développe un addon et qui fini par l'abandonner, si il nous a mis un max infini ou très large, son addon sera toujours annoncé comme compatible alors qu'il peux ne plus l'être, au cas où la non mise à jour du plugin peux avoir un impacte important (BDD, erreur php (renvoyant du http 500 ou plus légère (pourrissement inutile des log php)), le blogotext de l'utilisateur tombe en rideau et potentiellement (si l'addon touche à la bdd) perte de données.

En faisant l'inverse, ce sont les développeurs du core qui mettent en place les règles de compatibilité et de contrôle. En cas d'abandon de la maintenance d'un addon, au pire, il sera annoncé comme non compatible (et désactivé) alors qu'il le serait toujours (compatible), le core reste protégé et au pire, le blogotext de l'utilisateur tourne toujours, mais en "dégradé" et avec un risque de perte de données amoindris. L'autre avantage (pour les devs core), c'est que le développeur d'addon, si il utilise son addon, il sera "obligé" d'en assuré le suivi/mise à jour en modifiant la 'versions_compliancy' de son addon. L’inconvénient de ce système, est de devoir annoncer aux dévs d'addon les modifications du système d'addon avant de les passer en production pour qu'ils puissent avoir le temps de mettre à jour et de vérifier leur addon.

[BoboTiG]

Quand tu dis en faisant l'inverse, comment tu verrais la gestion des versions par le core ? Il faut bien que le dev d'un addon donne une version explicite, on ne peut pas le deviner. Ou j'ai manqué un truc ?

[remrem]

Point de vue addon : $GLOBALS['addons'][]['versions_compliancy'] => '3.7' L'addon est compatible/testé avec la 3.7.XXX, pas avec la 3.6 ou la 3.8.

tant que X.Y de blogotext = X.Y de l'addon => ok si X.Y de blogotext != X.Y de l'addon => le dev doit vérifier/mettre à jour sont addon.

Pas de version min (X.Y), si un plugin développé sous blogotext 3.7 est mise à jour sous blogotext 3.9, je ne pense pas que le développeur de l'addon aille tester ses modifications sous blogotext 3.7 et sous blogotext 3.8 :/ Si l'addon perd la compatibilité avec blogotext 3.7 et que le dev ne le teste pas/ne mets pas à jour son $GLOBALS['addons'][]['versions_compliancy']['min'], tu peux être sûr et certain que l'on rencontrera un cas où un utilisateur de blogotext viendra se plaindre/demandera un fix pour assurer la rétro compatibilité avec une veille version de blogotext (j'ai des clients/amis sous WP et je rencontre trop souvent des problèmes entre les MAJ non faites ou non cohérentes ou de rétro compatibilité, je pense que c'est pour ça, entres autres choses, que WP force un peu la main sur les mises à jour automatique de son système) (pour info http://sebsauvage.net/rhaa/ > BlogoText 0.9.3 :D).

Pas de version max (X.Y), ça ne donne aucune garantie que le dev de l'addon soit compatible avec les prochaines versions.

Si l'utilisateur de blogotext, veux la dernière version d'un addon, il utilise la version de blogotext et de l'addon qui fonctionne avec (testé), si l'addon ne prend pas en charge la dernière version de blogotext, soit l'utilisateur demande une mise à jour/validation au dev de l'addon, soit à la communauté.

C'est peut-être un poil rigide, mais ça me semble le plus sûr. A toi de voir quelle direction l'on prend.

[BoboTiG]

Mettons que je développe des addons, il faudrait que je fasse des copies pour BT 3.7, 3.8 et 3.9 même s'il n'y a aucun changement et que tout est compatible ?

Et d'un autre côté, les addons seront livrés avec la version de BT, pas de MàJ possible. Donc on ne risquera pas de trouver des addons obsolètes. C'est du côté du dépôt des addons qu'il va falloir gérer les différentes versions (en créant des tags par exemple). Quand on sera sûr de la prochaine version majeure, je créerai le tag 3.7 et tout les addons de ce tag seront livrés avec la version 3.7. Ça te semble correct ou on garde le schéma master == BT stable et dev == BT dev ?

[remrem]

C'est un poil rigide, mais je suis d'avis que l'on conserve uniquement les dernières versions. En gros, en s'inspirant du développement de debian : une version stable (master) qui contient la dernière version des addons, à l'annonce de la sortie prochaine d'une version X.Y (disons la 3.8) de blogotext

• on crée une release des addons pour avoir une version "stable" pour des addons compatible 3.7
• on laisse les devs mettre jour leurs addons tranquillement sur master Ainsi sur github, on aurait une release 3.7 de blogotext et une release 3.7 des addons

Pour la problématique du versioning des addons, on peut toujours mettre en place : $GLOBALS['addons'][]['versions_compliancy'] => array( '3.7' , '3.8' ) l'addon qui prétend à une compatibilité avec une version supérieure que la dernière version, on le bloque. Par contre le problème de la rétro compatibilité serait toujours là. A choisir, je préfère la solution précédente (release).

Qu'entends tu par :

les addons seront livrés avec la version de BT, pas de MàJ possible.

Tu comptes bloquer le développement et les release des addons ?

[BoboTiG]

OK, on part sur l'utilisation des release.

Tu comptes bloquer le développement et les release des addons ?

Non, du tout. Les addons seront figés avec la version de BT téléchargée. Mettons que je télécharge la prochaine version, disons 4.0 ; je me retrouverai avec BT 4.0 et les addons compatibles avec BT 4.0. J'aurai les MàJ de des addons si je mets à jour BT. On est sur la même longueur d'ondes ?

[remrem]

Je pense qu'il faut dissocier les mises à jour des addons et les mise à jour de BT à partir du moment ou la 'versions_compliancy' est repectée.

Je donne un cas fictif (qui sera à coup sûr réel, Loi de Murphy oblige) : j'ai mon plugin light SEO, qui fait de l'url rewriting, je suis sûr et certains que tôt ou tard, un utilisateur (ou moi-même) voudra une fonctionnalité ou signalera un bug. Si je dois attendre la prochaine release/MAJ de BT pour diffuser la MAJ de l'addon, le temps va paraître long... L'idéal c'est que je puisse pousser sur le github des addons mes mises à jours, que l'utilisateur puisse mettre à jour en allant chercher la mise à jour soit à la main, soit via un script.

Pour info, je réfléchis à un encart sur le dashboard admin pour la notification de MAJ de blogotext/addons disponible, l'idée fait son chemin, j'en reparlerai plus tard.

[BoboTiG]

Le dossier addons peut-être mis à jour manuellement :

cd addons
git pull origin master

Et pour les MàJ, il ne faut pas être trop intrusif, dans la page de maintenance il y a déjà ce qu'il faut pour prévenir l'utilisateur.

[remrem]

Qui si colle ? Au moins pour un process de base ?

[BoboTiG]

J'attends de voir tes modifs pour la gestion des addons et je peux m'y coller si tu veux.

[remrem]

Tu peux y aller, ça ne me dérange pas d'adapter plus tard pour que tout sois cohérent ;)

[remrem]

Je suis dessus

[remrem]

J'ai une mise à jour à pousser, là ça ne correspond pas à ce que l'on a dit (compatibilité major.minor)

[remrem]

Avec le PR #166 , le comportement est tel que désiré, compliancy doit être égale à major.minor, minus ne compte pas. A voir à l'usage si besoin d'un autre comportement. Je te laisse valider et cloturer.

[BoboTiG]

Nickel !