Désolé si vous l’avez mal pris. Je reformule :
La disparition de l’atttribut etat est souhaité et ne semble pas poser de problème technique s’il est déterminé autrement, notamment s’il apparait facultativement en complément de l’attribut version , sur le modèle de SemVer, avec une conversion semver/valeurs historiques (cf le tableau). Attention cependant à ne pas casser la compatibilité ascendante.
Le plugin SVP doit évoluer en splittant la partie « Référentiel » et la partie « Installation ».
Il en découle un ou plusieurs chantiers post sortie de la 4.0.
Il n’est actuellement pas envisageable de rendre l’attribut version optionnel dans le fichier paquet.xml pour les raisons techniques évoquées plus haut. Cette éventualité ne sera pas abordé en même temps que le ou les chantiers ci-dessus, voire jamais s’il n’y a pas moyen d’aménager les raisons techniques qui le rendent obligatoire à ce jour. Si j’essaie de résumer ces raisons techniques :
- Il n’y a pas de corrélation évidente entre un sous-répertoire de
plugins et la version du plugin de ce sous-répertoire.
- Un plugin n’est pas nécessairement installé depuis un « paquet » provenant d’un fichier zip.
- L’emplacement d’un plugin n’est pas définitif.
- Les calculs de gestion des dépendances de SPIP et de SVP s’appuie donc sur les versions trouvées dans les
paquet.xml de l’arborescence des dossiers plugins et plugins-dist (et squelettes-dist, ne l’oublions pas).
- Les données en base ne peuvent y suppléer, surtout si le référentiel a vocation à ne plus être distribué avec SPIP.
Quel serait l’intérêt de rendre l’attribut version optionnel ?
les trucs fastidieux
Dans SPIP, on trouve la version à 3 endroits :
- dans
ecrire/inc_version.php, la globale $spip_version_affichee entre autres,
- dans
ecrire/paquet.xml,
- dans les tags git ainsi que dans le nom du fichier zip du « paquet » SPIP.
Dans les plugins-dist :
- dans
paquet.xml,
- dans les tags git, sous 2 formes : la valeur conforme à celle du paquet.xml (LA version du plugin) et la version SPIP dans lequel il va être distribué.
Dans squelettes-dist :
- dans
paquet.xml,
- dans les tags git, sous 2 formes : la valeur conforme à celle du paquet.xml (LA version du plugin) et la version SPIP dans lequel il va être distribué.
Dans les autres plugins :
- dans
paquet.xml,
- dans les tags git : la valeur conforme à celle du paquet.xml (LA version du plugin).
Pour être cohérent, il faut donc modifier un fichier (ou 2 pour SPIP) ET créer un tag (ou 2 pour les plugins-dist) quand on veut distribuer une nouvelle version.
L’intérêt, en apparence mineur, ce serait de n’avoir qu’une seule opération à faire en vue de distribuer une nouvelle version: créer un tag (et pourquoi pas, pour les « plugins-dist » et « squelettes-dist », un seul tag mais c’est un autre sujet … et pourquoi pas, pour SPIP aussi, mais c’est encore un autre sujet …).
La séparation des responsabilités
Ce qui découle du point ci-dessus, c’est qu’on peut dès lors séparer le geste de faire des commits de celui de distribuer une nouvelle version. à chaque geste technique, une responsabilité différente : un commit, je développe, un tag, je distribue.
Parfois, on corrige un petit truc et un commit suffit.
Parfois, on va entamer un processus de développement un peu plus long et de durée incertaine, dans master ou dans un branche parallèle, peu importe, mais on est, tout au long de ce processus, pas sûr de quand et sous quelle forme de X.Y.Z ce sera distribué « à la fin ». Dans ces moment-là, on ne modifie pas les attributs version+etat et pour autant, d’autres utilisateurs peuvent installer le plugin et là, on ne sait pas distinguer dans l’administration des plugins à quelle moment du processus de développement on se trouve. Est-ce qu’on est dans la 1.0.0 du dernier tag ? ou bien dans la 1.0.0 quelque part sur un commit de la branche master ou le fichier paquet.xml n’a pas encore été changé ? Ou encore : « Je suis en 1.2.3 mais je ne trouve pas le zip qui correspond pour que mon voisin essaie la même version et dans la branche git, on est en 1.2.7 … »
Entre les deux, il y a aussi différentes situations possibles.
Bref, pour remédier à ça, on peut être tenté de modifier systématiquement la version dans le fichier à chaque commit, ou bien de ne jamais la modifier et de « distribuer » avec des tags sans rapport avec la version du fichier xml. Ou alors, on va basculer d’un etat à un autre, mettre à jour la version, mais le z seulement, et quid du y, etc…
Bref, un autre intérêt, c’est d’enlever les risques d’ambiguïté entre les tags git et le contenu des fichiers xml
est-ce qu’il y a d’autres intérêts ?
Oui, notamment pour l’introduction du niveau de stabilité à travers semver et le fait de passer d’une habitude à une autre (de alpha, beta à experimental, test, stable). On pourrait parler d’obsolescence (ou d’abandon) aussi. Et bien sûr d’une « passerelle » avec composer.
Mais comme ce post est déjà assez long, je vais m’arrêter là pour le moment. 
