[spip-dev] SVP et les branches SPIP

Hello,

Dans ma quête du SVP en mode nectar, après les catégories, je pensais m’attaquer aux branches SPIP qui y sont décrites.
Aujourd’hui, concernant la gestion des branches, on a dans SVP :

  • Une balise SVP_BRANCHES_SPIP qui renvoie la liste des branches (contenue dans une globale voir après) avec un formatage adéquat pour l’affichage et quelques options.
    Cette balise n’est jamais utilisée dans SVP, elle ne sert à priori que pour Plugins SPIP pour l’affichage de la compatibilité.
    ==> je propose de supprimer cette fonction de SVP tout simplement de la 3.3 car tant que Plugins SPIP reste en 3.2 on aura pas de souci et comme il disparaitra surement au profit de Contrib il faudra traiter cette balise dans le cadre de la refonte.

  • deux define et une globale, à savoir:

if (!defined('_SVP_VERSION_SPIP_MIN')) {
   /**
    * Version SPIP minimale quand un plugin ne le precise pas
    * Version SPIP correspondant à l'apparition des plugins */
   define('_SVP_VERSION_SPIP_MIN', '1.9.0');
}

if (!defined('_SVP_VERSION_SPIP_MAX')) {
   /**
    * Version SPIP maximale
    * Pour l'instant on ne connait pas la borne sup exacte */
   define('_SVP_VERSION_SPIP_MAX', '3.3.999');
}

/**
 * Liste des branches significatives de SPIP et de leurs bornes (versions min et max)
 * À mettre a jour en fonction des sorties
 * @global array $GLOBALS ['infos_branches_spip']
 */
$GLOBALS['infos_branches_spip'] = array(
   '1.9' => array(_SVP_VERSION_SPIP_MIN, '1.9.2'),
   '2.0' => array('2.0.0', '2.0.999'),
   '2.1' => array('2.1.0', '2.1.999'),
   '3.0' => array('3.0.0', '3.0.999'),
   '3.1' => array('3.1.0', '3.1.999'),
   '3.2' => array('3.2.0', '3.2.999'),
   '3.3' => array('3.3.0', _SVP_VERSION_SPIP_MAX),
);

La globale est utilisée dans la balise précédemment citée.
En outre, et c’est le principal, ces définitions sont utilisées par SVP pour déterminer et normaliser les intervalles de compatibilité des plugins lors de la lecture des fichiers XML et la création des plugins en base de données.
En particulier c’est le cas avec les fonctions compiler_branches_spip(), fusionner_intervalles(), extraire_bornes()…

Néanmoins, je suis peut-être un peu pinailleur, mais je trouve que ces déclarations n’ont rien à faire avec SVP qui traite des plugins mais uniquement avec SPIP.
En outre, il existe déjà dans SPIP des define liés à la version courante que l’on modifie à chaque release.
Et donc il faut aussi modifier ces déclarations SVP à chaque release.

Ne serait-il pas intéressant de transférer ces déclarations dans SPIP pour plus de cohérence et pour une gestion simplifiée des releases ?
Dans ce cas, on pourrait en profiter pour améliorer le tableau des branches en rajoutant l’état de la branche (maintenu, en dev, obsolète) voire d’autres infos si cela a du sens.
Le tableau pourrait même devenir un json uniquement (avec une petite api de lecture), seuls les define min et max serait ajouté à inc_version ou autre include.

Je sais que ce n’est pas essentiel mais comme je bosse sur SVP ces derniers autant avancer un peu.
Votre avis ?

Je n'ai pas creusé la réflexion plus loin que ça, mais la gestion de versions (et la connaissance des versions existantes), c'est plutôt un boulot pour Composer.

Du coup, et si le passage à Composer est toujours un projet dans l'air du temps (?), c'est peut être pas la peine d'aller trop loin dans cette direction en codant des trucs spécifiques pour les retirer ensuite ?

Mes deux centimes...

Hop,

Hello,

Hop,

Je n’ai pas creusé la réflexion plus loin que ça, mais la gestion de
versions (et la connaissance des versions existantes), c’est plutôt un
boulot pour Composer.

Bonne idée que de faire du ménage dans SVP, mais, comme nicod, je pense
que ça n’est peut-être pas le moment de migrer ces infos dans le core
alors que composer devrait prendre ça en charge à terme.

Vous êtes sur que Composer saurait fournir une information comme celle contenue dans ce tableau (en y ajoutant les états des branches) ?

$GLOBALS['infos_branches_spip'] = array(
   '1.9' => array(_SVP_VERSION_SPIP_MIN, '1.9.2'),
   '2.0' => array('2.0.0', '2.0.999'),
   '2.1' => array('2.1.0', '2.1.999'),
   '3.0' => array('3.0.0', '3.0.999'),
   '3.1' => array('3.1.0', '3.1.999'),
   '3.2' => array('3.2.0', '3.2.999'),
   '3.3' => array('3.3.0', _SVP_VERSION_SPIP_MAX),
);

On a quand même l’ensemble des branches et leur intervalle qu’elles soient maintenues ou obsolètes.
Si oui, c’est vrai qu’on peut attendre même si à mon avis ça ne mangerait pas de pain (bio).

Par contre, pour la balise je pense qu’on peut la virer sans état d’âmes et la reporter dans le nouveau Contrib.

Donc je sais pas trop…