[spip-dev] dependance des plugin envers SPIP, choix de version avec la branche 1.9.3

952025d4c0b44044bbfe · Janvier 20, 2008, 4:15

dépendance des plugin envers SPIP, choix de version avec la branche 1.9.3

Bonjour ,
bonne années à ceux auquels je n'ai pas adressé de voeux,

L'année dernière (2007) a été ajoutée la possibilité d'ajouter, dans la
déclaration plugin.xml (voir http://www.spip-contrib.net/Plugin-xml ) de
chaque plugin, un élément de gestion des dépendance (avec
<necessite> on peut spécifier des versions de plugin et de SPIP
minimale et maximale). En particulier la version de SPIP requise (voir
http://trac.rezo.net/trac/spip/changeset/8961
http://trac.rezo.net/trac/spip/changeset/8977
http://trac.rezo.net/trac/spip/changeset/9023 )

Le système de gestion des dépendances des plugins envers les
versions de SPIP doit permettre d'indiquer une version minimale et
maximale (et le reste du cahier des charges).

critères supplémentaires personnels
- utilise version_compare
( http://fr.php.net/manual/fr/function.version-compare.php )
- utilise une valeur au format conseillé par la documentation de
version_compare ( http://trac.rezo.net/trac/spip/ticket/687 )
- utilise le même numéro de version que celui affiché dans la partie
privée ou dans http://www.spip.net/fr_rubrique155.html
- limiter le nombre de variables de version différentes
( http://trac.rezo.net/trac/spip/ticket/972 )

Pour la version de SPIP c'est $spip_version_code qui est pris pour
comparaison. $spip_version_code a été introduit par
http://trac.rezo.net/trac/spip/changeset/7071#file3 17/08/2006

Le code chargé des comparaisons, dans
http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc/plugin.php ,
a évolué pour utiliser plugin_version_compatible
http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc/plugin.php#L88
http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc/plugin.php#plugin_version_compatible
et version_compare
http://trac.rezo.net/trac/spip/changeset/8961
http://trac.rezo.net/trac/spip/changeset/8977
http://trac.rezo.net/trac/spip/changeset/9023 , ce qui rempli une de mes attentes.

La variable $spip_version_code est passée progressivement à un
format plus proche de « m.n.o.p », avec séparation interne, puis
passage en chaine de caractères, se rapprochant donc du format de
numérotation générale de SPIP.

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php
http://trac.rezo.net/trac/spip/log/spip/ecrire/inc_version.php

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=7071#L226 17/08/2006
$spip_version = 1.917;
$spip_version_affichee = '1.9';
$spip_version_code=1.9001;

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=8768#L281 22/02/2007
$spip_version = 1.926;
$spip_version_affichee = '1.9.3 dev';
$spip_version_code = 1.9207;

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=8963#L283 01/04/2007
$spip_version = 1.935;
$spip_version_affichee = '1.9.3 dev';
$spip_version_code = 1.9250;

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=9023#L283 12/04/2007
$spip_version = 1.935;
$spip_version_affichee = '1.9.3 dev';
$spip_version_code = '1.9250';

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=11042#L292 04/01/2008
$spip_version = 11042;
$spip_sql_version = 1;
$spip_version_affichee = '1.9.3 dev';
$spip_version_code = '1.9303';

Cependant les dernières modifications

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=11056#L292 10/01/2008
$spip_version_code = 11056;
$spip_version = 11042;
$spip_sql_version = 1;
$spip_version_affichee = '1.9.3 dev';

http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc_version.php?rev=11088#L292 17/01/2008
$spip_version_code = 11056;
$spip_version = 11088;
$spip_sql_version = 1;
$spip_version_affichee = '1.9.3 dev';

éloignent le code de mes souhaits (sans parler des réglages des
plugins qui ne fonctionnent plus pour demander une version précise
de SPIP, car c'est normal pour une version en développement).

Pire, il n'y a plus de gestion des branches. En effet, supposons que,
dans trois mois, soit publiée une version de SPIP 1.9.3, avec
$spip_version_code = 15000, suivie d'une version 1.9.4 avec
$spip_version_code = 16001. Les plugins nécessitant la version 1.9.4
mettent <necessite id='spip' version='[16001;]' />. Supposons
qu'ensuite des corrections soient faites dans la branche 1.9.3, avec
publication d'une version 1.9.3.1 (ou 1.9.3a si vous préférez) à
$spip_version_code = 16101. Un plugin demandant 1.9.4 minimum,
donc 16001, sera alors accepté par le code de inc/plugin.php de cette
dernière (chronologiquement) version.

Sans forcément reprendre aveuglement mes propositions
( http://trac.rezo.net/trac/spip/ticket/687
et http://trac.rezo.net/trac/spip/ticket/972 ), je vous prie tout de même
d'améliorer l'existant. Le format de variable de version de SPIP à
utiliser dans <necessite id='spip' version='[16001;]' /> n'est pas encore
officiel pour une version stable de SPIP, donc les plugins peuvent
encore changer, mais je ne suis pas certain que ce soit aussi simple
une fois une version publiée et que des plugins commenceront à
utiliser la commande par des personnes qui suivent le développement
de SPIP de moins près. Si il pouvoit y avoir un format stable et
pérenne serait un plus.

Notes concernant le format 1.m.n :
- la fonction version_compare
http://fr.php.net/manual/fr/function.version-compare.php permet
d'indiquer des pré-version avec « alpha » et « beta »; « 1.9.3 alpha 1 »
est possible est sera distinct de « 1.9.3 alpha 2 s;
- si il est possible d'incrémenter $spip_version_code (au format actuel
ou au format d'il y a un mois) très souvent, alors il me semble possible
d'incrémenter 1.9.3 alpha 1.1, alpha 1.2 (etc.) aussi.
- les versions publiées pourraient être numérotées avec
- version.0.j pour les modifications du code
- version.1 à la première publication de version
( http://trac.rezo.net/trac/spip/#Anciennesversions )
- et ainsi de suite version.1.j ... version.2 ... version.2.j ... version.i.j

esj · Janvier 20, 2008, 5:52

....

Le système de gestion des dépendances des plugins envers les
versions de SPIP doit permettre d'indiquer une version minimale et maximale

...

Pour la version de SPIP c'est $spip_version_code qui est pris pour comparaison.

...

La variable $spip_version_code est passée progressivement à un
format plus proche de « m.n.o.p », avec séparation interne, puis
passage en chaine de caractères, se rapprochant donc du format de
numérotation générale de SPIP.

..

Cependant les dernières modifications éloignent le code de mes souhaits:

$spip_version_code = 11056;
$spip_version = 11088;

...

Pire, il n'y a plus de gestion des branches.

Il n'y a effectivement plus de mention des branches dans les deux variables ci-dessous, tout simplement parce que dans les faits cette gestion n'existe déjà plus. Les nombreuses nouveautés arrivées dans la SVN depuis la sortie de la 1.9.2 militent clairement pour que la prochaine version de SPIP ne se nomme PAS 1.9.3, car l'incrément du 3e chiffre ne reflèterait pas l'importance de ces changements.

Le nommage de la prochaine version officielle de SPIP n'est pas encore arrêté, mais le fait d'avoir une version en développement, circulant déjà beaucoup, qui porte comme nom "X dev" alors que la version stable ne s'appellera probablement pas "X" nous a conduit d'ores et déjà à adopter une autre stratégie pour donner aux plugins les informations nécessaires à la compatibilité.

Les deux variables $spip_version_code et $spip_version ont donc maintenant des valeurs indépendantes du nom officiel de la version de SPIP (ce qui laisse toute liberté pour lui trouver un nom) et fournissent une information plus précise. Mieux: chaque changement potentiellement problématique s'accompagne à présent d'un changement de la variable concernée (spip_version pour un chgt SQL, spip_version_code pour un chgt dans les signatures de fonctions de PHP). En prenant de plus comme valeur le numéro du dépot SVN, on permet aux auteurs de plugins de consulter rapidement la liste des changements pouvant poser des problèmes à leur propre code. Il suffit de regarder l'histoire du fichier inc_version qui ne change pratiquement que pour ces deux variables:
http://trac.rezo.net/trac/spip/log/spip/ecrire/inc_version.php

En d'autres termes: la bonne solution n'est pas toujours de s'accrocher aux branches.

Committo,Ergo:Sum

esj · Janvier 20, 2008, 6:05

....

Le système de gestion des dépendances des plugins envers les
versions de SPIP doit permettre d'indiquer une version minimale et maximale

...

Pour la version de SPIP c'est $spip_version_code qui est pris pour comparaison.

...

La variable $spip_version_code est passée progressivement à un
format plus proche de « m.n.o.p », avec séparation interne, puis
passage en chaine de caractères, se rapprochant donc du format de
numérotation générale de SPIP.

..

Cependant les dernières modifications éloignent le code de mes souhaits:

$spip_version_code = 11056;
$spip_version = 11088;

...

Pire, il n'y a plus de gestion des branches.

Il n'y a effectivement plus de mention des branches dans les deux variables ci-dessous, tout simplement parce que dans les faits cette gestion n'existe déjà plus. Les nombreuses nouveautés arrivées dans la SVN depuis la sortie de la 1.9.2 militent clairement pour que la prochaine version de SPIP ne se nomme PAS 1.9.3, car l'incrément du 3e chiffre ne reflèterait pas l'importance de ces changements.

Le nommage de la prochaine version officielle de SPIP n'est pas encore arrêté, mais le fait d'avoir une version en développement, circulant déjà beaucoup, qui porte comme nom "X dev" alors que la version stable ne s'appellera probablement pas "X" nous a conduit d'ores et déjà à adopter une autre stratégie pour donner aux plugins les informations nécessaires à la compatibilité.

Les deux variables $spip_version_code et $spip_version ont donc maintenant des valeurs indépendantes du nom officiel de la version de SPIP (ce qui laisse toute liberté pour lui trouver un nom) et fournissent une information plus précise. Mieux: chaque changement potentiellement problématique s'accompagne à présent d'un changement de la variable concernée (spip_version pour un chgt SQL, spip_version_code pour un chgt dans les signatures de fonctions de PHP). En prenant de plus comme valeur le numéro du dépot SVN, on permet aux auteurs de plugins de consulter rapidement la liste des changements pouvant poser des problèmes à leur propre code. Il suffit de regarder l'histoire du fichier inc_version qui ne change pratiquement que pour ces deux variables:
http://trac.rezo.net/trac/spip/log/spip/ecrire/inc_version.php

En d'autres termes: la bonne solution n'est pas toujours de s'accrocher aux branches.

Committo,Ergo:Sum

cerdic · Janvier 20, 2008, 9:41

Si NK a raison, il faut que spip_version_code informe également sur la branche.

L'information <necessite id='spip' version='[16512;]' />
ne permet plus de discriminer quelle branche cela concerne ou non, ce qui est grave.
Il faut revenir en arrière sur ce point.

Cédric

esj · Janvier 20, 2008, 10:20

Bon, puisque le débat est lancé, allons jusqu'au bout.

Un constat d'abord: les numérotations des versions de SPIP sont depuis un bon moment contestables et contestées. Cela fait trop longtemps que ça dure pour que cela soit juste une négligence occassionelle, et il doit y avoir des raisons profondes.

Ces raisons, à mon avis, est que SPIP étend à chaque version son périmètre d'intervention. C'était un outil de publication Web clés en main, ça devient une plateforme de développement dont l'outil de publication est l'application phare. Il en découle deux choses.

La première est qu'il est impossible d'appliquer une notion de branche de développement à un objet dont la croissance est moins arborescente que rhyzomatique (les lecteurs de Deleuze me comprendront sans peine). Appliquer une taxonomie à un objet qui n'en relève pas ne peut que semer la confusion.

La deuxième est que la croissance de SPIP pose des problèmes de perception entre ce qui est du domaine de l'interface officielle sur laquelle une compatibilité maximale entre versions est demandée, et ce qui relève de choix d'implémentations temporaires pour faire tourner l'application phare. Beaucoup de contributeurs vivent comme des frustrations le fait que des fonctionnalités de SPIP exigent des ruptures de compatibilité dans ces choix d'implémentation temporaires. Ces ruptures iront en diminuant à mesure que l'interface officielle se précisera, mais il ne faut pas cacher qu'il y en aura encore à venir avant que SPIP ait terminé sa mue.

Pour réduire au minimum confusion et frustration, je pense donc raisonnable d'abandonner la notation arborescente et de ne plus utiliser que la numérotation SVN.

Committo,Ergo:Sum

d6bcc728454b294b52e0 · Janvier 20, 2008, 11:30

Heu comment on repère une version stable ?

Comment on gere les bugs sur ces versions stables s’il n’y a plus de branches

A+

epilibre · Janvier 20, 2008, 11:37

> En d'autres termes: la bonne solution n'est pas toujours de
> s'accrocher aux branches.
Si NK a raison, il faut que spip_version_code informe également sur
la branche.

L'information <necessite id='spip' version='[16512;]' />
ne permet plus de discriminer quelle branche cela concerne ou non, ce
qui est grave.

Il suffit peut-être de le préciser :
<necessite id='spip' version='[16512;]' branche='spip1.9.2' />
non ?

.Gilles

esj · Janvier 21, 2008, 6:38

Pour réduire au minimum confusion et frustration, je pense donc
raisonnable d'abandonner la notation arborescente et de ne plus
utiliser que la numérotation SVN.

Heu comment on repère une version stable ?

Comme j'ai dit le nom d'une version stage reste à trouver librement.
Au minimum, le fait qu'il n'y ait pas "dev" ou "alpha" etc pourrait suffire

Comment on gere les bugs sur ces versions stables s'il n'y a plus de branches

Sortir des versions correctives avec une sous-numérotation les indiquant reste évidemment souhaitable mais parler de branches pour des choses aussi minimes serait trompeur. La derniere version stable se nomme "1.9.2c". Le "c" renvoie à une réalité compréhensible,
le reste ne renvoie à rien de logique.

Committo,Ergo:Sum

cerdic · Janvier 21, 2008, 9:10

Committo,Ergo:sum a écrit :

Il n'y a effectivement plus de mention des branches dans les deux
variables ci-dessous, tout simplement parce que dans les faits cette
gestion n'existe déjà plus. Les nombreuses nouveautés arrivées dans la
SVN depuis la sortie de la 1.9.2 militent clairement pour que la
prochaine version de SPIP ne se nomme PAS 1.9.3, car l'incrément du 3e
chiffre ne reflèterait pas l'importance de ces changements.
...
En d'autres termes: la bonne solution n'est pas toujours de
s'accrocher aux branches.


Si NK a raison, il faut que spip_version_code informe également sur la branche.

L'information <necessite id='spip' version='[16512;]' />
ne permet plus de discriminer quelle branche cela concerne ou non, ce qui est grave.
Il faut revenir en arrière sur ce point.

Bon, puisque le débat est lancé, allons jusqu'au bout.

Pour être complet dans l'historique, c'est un débat que nous avions eu entre nous et sur lequel nous étions tombés tous d'accord, mais NK a mis le doigt sur un problème que nous avions oublié (et moi en particulier, puisque j'ai commis ce <necessite> à l'origine), ce qui relance donc ce débat.

Comme l'explique Emmanuel, on cherche à avoir une lisibilité meilleure du numéro de version ; mais du coup la question de pose de savoir si, en pratique, on peut perdre complètement la distinction des branches dans la notion de compatibilité des plugins avec le noyau.

Cédric

esj · Janvier 21, 2008, 9:31

oui, j'allais écrire à peu près la même chose, ne serait-ce le mot "branche".

Comme j'ai dit, à coté des deux variables $spip_version et $spip_version_code, il y a toujours $spip_version_affichee qu'on peut nommer comme bon nous semble.
Les deux premières variables donnnent des indications très précises sur le dernier numéro SVN ayant créé des changements, la troisième doit donner une indication plus synthétique. Le problème n'est pas niable, mais il peut se traiter autrement que par un retour en arrière.

Committo,Ergo:Sum

cerdic · Janvier 21, 2008, 10:32

Committo,Ergo:sum a écrit :

L'information <necessite id='spip' version='[16512;]' />
ne permet plus de discriminer quelle branche cela concerne ou non, ce
qui est grave.


Il suffit peut-être de le préciser :
<necessite id='spip' version='[16512;]' branche='spip1.9.2' />
non ?

oui, j'allais écrire à peu près la même chose, ne serait-ce le mot "branche".

Comme j'ai dit, à coté des deux variables $spip_version et $spip_version_code, il y a toujours $spip_version_affichee qu'on peut nommer comme bon nous semble.
Les deux premières variables donnnent des indications très précises sur le dernier numéro SVN ayant créé des changements, la troisième doit donner une indication plus synthétique. Le problème n'est pas niable, mais il peut se traiter autrement que par un retour en arrière.

Oui, par contre, les plugins arrivants (parfois) à être compatibles multibranches, on doit pouvoir le specifier.

Cela se faisait sur le principe par
version='[1.9.1;1.9.3]'
pour specifier de 1.9.1 à 1.9.3 inclus

J'hésite du coup entre :
- demander un necessite par branche ?

le terme necessite perdant alors son sens, car certaines directives pouvant ne pas être respectées... (pour mémoire il peut deja y avoir plusieurs necessite, pour specifier la dependance à d'autres plugins, mais chacun devant alors être respecté).

- concatener branche et version code dans l'attribut version de necessite ?
<necessite id='spip' version='[1.9.1.11051;1.9.3.16512]' />

et donc dans tous les cas, il faut effectivement que l'on ait une information de branche stockee dans une des variables.
Cédric

d6bcc728454b294b52e0 · Janvier 21, 2008, 10:32

Pas de pb là dessus, il y a une branche 192 patchée donc qui prend elle aussi un numéro de révision.

Donc en se grattant la tête il y a 2 chose distincte un “nom” de version stable et un numéro de révision.

On pourrait se baser sur la nomenclature des écureuil (hihi) (même si spip est déjà un polatouche )

RealET · Janvier 21, 2008, 11:06

* cedric.morin@yterium.com tapuscrivait, le 21/01/2008 11:32:

Committo,Ergo:sum a écrit :



L'information <necessite id='spip' version='[16512;]' />
ne permet plus de discriminer quelle branche cela concerne ou non, ce
qui est grave.


Il suffit peut-être de le préciser :
<necessite id='spip' version='[16512;]' branche='spip1.9.2' />
non ?


oui, j'allais écrire à peu près la même chose, ne serait-ce le mot "branche".

Comme j'ai dit, à coté des deux variables $spip_version et $spip_version_code, il y a toujours $spip_version_affichee qu'on peut nommer comme bon nous semble.
Les deux premières variables donnnent des indications très précises sur le dernier numéro SVN ayant créé des changements, la troisième doit donner une indication plus synthétique. Le problème n'est pas niable, mais il peut se traiter autrement que par un retour en arrière.


Oui, par contre, les plugins arrivants (parfois) à être compatibles multibranches, on doit pouvoir le specifier.

Cela se faisait sur le principe par
version='[1.9.1;1.9.3]'
pour specifier de 1.9.1 à 1.9.3 inclus

J'hésite du coup entre :
- demander un necessite par branche ?

<necessite id='spip' version='[11051;]' branche='spip1.9.1' />
<necessite id='spip' version='[13043;]' branche='spip1.9.2' />
<necessite id='spip' version='[16512;]' branche='spip1.9.3' />

le terme necessite perdant alors son sens, car certaines directives pouvant ne pas être respectées... (pour mémoire il peut deja y avoir plusieurs necessite, pour specifier la dependance à d'autres plugins, mais chacun devant alors être respecté).

- concatener branche et version code dans l'attribut version de necessite ?
<necessite id='spip' version='[1.9.1.11051;1.9.3.16512]' />

et donc dans tous les cas, il faut effectivement que l'on ait une information de branche stockee dans une des variables.
Cédric

Avec un autre point à prendre en considération : <necessite> n'est vérifié que dans la 1.9.3 Dev SVN.
Autrement dit, actuellement, il n'a aucune incidence en 1.9.2c.
Donc, c'est de l'avenir dont on parle, pas du présent.