Utiliser spip_version_compare() dans un squelette

Dev
1

J’essaie de faire un test sur le numéro de version dans un squelette, sur un Spip 4 GIT, #SPIP_VERSION me donne 4.0.0 GIT [4.0: bb50a8b4]

Mais le test suivant renvoie false :

[(#SPIP_VERSION|spip_version_compare{4.0.0,>=}|var_dump)]

Faut comparer avec autre chose que #SPIP_VERSION ?

2

SPIP : Fichier ecrire/inc/utils.php et https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/utils.php#L3560

ça parse des versions « sémantiques », puis fait appel à la fonction php version_compare() donc pas de GIT ... :slight_smile:

si tu ajoutes |replace{ GIT.*}|spip_version_compare{...} ça donne quoi ?

3

non, je dis des bétises :slight_smile:

php -r 'echo (version_compare("4.0.0", "4.0.0 GIT [truc]", ">=") ? "plus grand ou egal" : "plus petit") . PHP_EOL;' // plus grand ou egal
php -r 'echo (version_compare("3.2.11", "4.0.0 GIT [truc]", ">=") ? "plus grand ou egal" : "plus petit") . PHP_EOL;' // plus petit
4

Tu peux tester #CONST{_SPIP_VERSION_ID} qui retourne 40000

5

Aaaah, mais j’inversais les 2 numéros semble-t-il :stuck_out_tongue:

[(#VAL{4.0.0}|spip_version_compare{#SPIP_VERSION, >=}|?{plus grand ou égal, plus petit})]

Comme ça c’est mieux, merci à tous les 2.

6

Je me dis que #SPIP_VERSION devrait retourner une version valide au sens semver, et mettre le détail du vcs dans la partie build, tel que 4.0.0+git-4.0-bb50a8b4 ; un des seuls soucis serait de caser le nom de la branche qui peut ne pas être valide du <build> semver… ou alors on ne mettrait que le hash de commit… 4.0.0+git-bb50a8b4

7

Rectificatif pour les gens qui suivent par mail : le code précédent était tout pourri, le bon :

[(#VAL{4.0.0}|spip_version_compare{#SPIP_VERSION, >=}|?{plus grand ou égal, plus petit})]

Moralité : ne jamais écrire au clavier de l’oeil gauche tout en suivant la cuisson du riz de l’'oeil droit.

8

4.0.0 correspond à un tag, une version stable précise. Normalement, il n’y a qu’un seul « build » pour cette version, donc un seul identifiant semver. Normalement hein … :slight_smile:

Si tu es sur un commit de la branche de maintenance (4.0) il faudrait mieux qu’on n’ait pas 4.0.0, mais 4.0 tout court (enfin… modulo le complément que tu proposes). Parce que ce n’est plus la 4.0.0, c’est peut-être la future 4.0.1…

Faudrait regarder du coté de composer qui a un système d’alias de branches :

  • master → dev-master → éventuellement synonyme de 4.1.0-dev
  • super-fonctionalite → dev-super-fonctionalite
  • 4.0 → 4.0.x-dev
1 « J'aime »
9

Le 23/08/2021 à 14:19, JamesRezo via Discuter de SPIP a écrit :

Si tu es sur un commit de la branche de maintenance (|4.0|) il faudrait mieux qu’on n’ait pas |4.0.0|, mais |4.0| tout court (enfin… modulo le complément que tu proposes). Parce que ce n’est plus la 4.0.0, c’est peut-être la future 4.0.1…

+1 et ce qui est sûr c’est que quelque soit la manière de nommer (4.0.Z+1-dev ou avec des -git123build), dès qu’on fait une release, sur n’importe quelle branche (donc y compris les branches de maintenance), alors la branche Git (master bien sûr mais aussi 3.2 etc) doit immédiatement être augmentée dans sa version pour que les plugins puissent discriminer (si par ex un plugin est codé en tenant compte d’un ajout ou correction faite sur la version Git qui n’est pas encore release, j’ai des exemples).

–
RastaPopoulos