[SPIP Zone] [Spip-zone-commit] r104775 - _plugins_/saisie_liste/trunk

Archives Zone
1

Le 6 juin 2017 à 11:01, Cédric Morin <cedric@yterium.com> a écrit :

J'en profite pour tordre le cou à cette légende urbaine :
la génération des zips ne prends en compte que les date de dernier commit,
le changement de z sur la version du plugin ne change RIEN.

Sans doute à l'origine de cette légende le fait que parfois la génération
du paquet bloque et un nouveau commit le déclenche, mais il suffirait de
commit n'importe quoi dans un fichier readme pour avoir le même résultat.

Le changement de x ou y ou z permet tout simplement à SVP de voir que le
plugin a été mise à jour. Cela convient pour des installations du plugin
déjà réalisées avant le changement de numéro.
Pour toute nouvelle installation après le changement de numéro (ou même
tout simplement un commit), SVP téléchargera la dernière version de
l'archive du plugin.

Exemple :
- Le plugin Toto est à la version 1.2.3. Cette version est disponible
depuis le 1er février.
- M. Dupont a installé ce plugin sur son site le 2 février.
- L'auteur du plugin Toto a depuis le 3 février apporté quelques correctifs
et améliorations à son plugin. Il a fait donc des commits mais n'a pas
changé le numéro. Son dernier commit date du 14 février.
- Mme Martin a installé le plugin Toto le 15 février par SVP.

Dans ce contexte, Mme Martin aura dans la version du 15 février tous les
commits de l'auteur du plugin. Choses que n'a pas M. Dupont. Pourtant, tous
les deux ont la version 1.2.3 du plugin Toto.

L'auteur du plugin Toto se dit qu'il faut changer le numéro de son plugin.
Il commite le 1er mars la version 1.2.4.
M. Dupont et Mme Martin voit le 2 mars qu'il y a une mise à jour du plugin
car SVP a détecté la nouvelle version.

Voilà.

:slight_smile:

--
Cédric

spip-zone-commit@rezo.net a écrit :

Author: bystrano@gmx.ch

Date: 2017-06-06 10:01:43 +0200 (Tue, 06 Jun 2017)
New Revision: 104775

Modified:
    _plugins_/saisie_liste/trunk/paquet.xml
Log:
up de z

Contrairement à ce que je pensais, il faut le faire pour déclencher la
génération d'un nouveau zip.

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman
/listinfo/spip-zone-commit

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman
/listinfo/spip-zone-commit

2

Est-ce que je suis le seul à trouver cela confus à tous les niveaux ?

À aucun moment un numéro de version de plugin ne garantit le code du plugin, c’est quand même un peu idiot…

3

Le 6 juin 2017 à 22:08, Debondt Didier a écrit :

Est-ce que je suis le seul à trouver cela confus à tous les niveaux ?

Ce qu'il faut retenir c'est juste qu'il faut penser à mettre à jour les

numéros de version quand on fait des modifications de code.

À aucun moment un numéro de version de plugin ne garantit le code du
plugin, c'est quand même un peu idiot…

En fait quand on utilise un système de versionnage de code, chaque "commit"
est en soi déjà une version :wink: Les "tags" et les "branches" sont une
organisation en plus sur lesquels vont s'appuyer les "releases" (qui sont
appelés "versions" ici) pour les utilisateurs.
Et SVP suit la logique des utilisateurs et regarde le numéro de version
(release). Et cette information est mise à jour dans un fichier XML de
méta-données car les plugins sont distribués par zip (SVP n'a pas à se
soucier des "commit" sur Svn ou Git ou autre)
Pour garantir le code, comme tu dis, il faut aller chercher directement
dans le système de versionnage du code...

Didier

Le 06/06/17 à 11:22, Ybbet Spip a écrit :

Le 6 juin 2017 à 11:01, Cédric Morin <cedric@yterium.com> a écrit :

J'en profite pour tordre le cou à cette légende urbaine :
la génération des zips ne prends en compte que les date de dernier
commit, le changement de z sur la version du plugin ne change RIEN.

Sans doute à l'origine de cette légende le fait que parfois la génération
du paquet bloque et un nouveau commit le déclenche, mais il suffirait de
commit n'importe quoi dans un fichier readme pour avoir le même résultat.

Le changement de x ou y ou z permet tout simplement à SVP de voir que le
plugin a été mise à jour. Cela convient pour des installations du plugin
déjà réalisées avant le changement de numéro.
Pour toute nouvelle installation après le changement de numéro (ou même
tout simplement un commit), SVP téléchargera la dernière version de
l'archive du plugin.

Exemple :
- Le plugin Toto est à la version 1.2.3. Cette version est disponible
depuis le 1er février.
- M. Dupont a installé ce plugin sur son site le 2 février.
- L'auteur du plugin Toto a depuis le 3 février apporté quelques
correctifs et améliorations à son plugin. Il a fait donc des commits mais
n'a pas changé le numéro. Son dernier commit date du 14 février.
- Mme Martin a installé le plugin Toto le 15 février par SVP.

Dans ce contexte, Mme Martin aura dans la version du 15 février tous les
commits de l'auteur du plugin. Choses que n'a pas M. Dupont. Pourtant, tous
les deux ont la version 1.2.3 du plugin Toto.

L'auteur du plugin Toto se dit qu'il faut changer le numéro de son plugin.
Il commite le 1er mars la version 1.2.4.
M. Dupont et Mme Martin voit le 2 mars qu'il y a une mise à jour du plugin
car SVP a détecté la nouvelle version.

Voilà.

:slight_smile:

--
Cédric

spip-zone-commit@rezo.net a écrit :

Author: bystrano@gmx.ch

Date: 2017-06-06 10:01:43 +0200 (Tue, 06 Jun 2017)
New Revision: 104775

Modified:
    _plugins_/saisie_liste/trunk/paquet.xml
Log:
up de z

Contrairement à ce que je pensais, il faut le faire pour déclencher la
génération d'un nouveau zip.

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman
/listinfo/spip-zone-commit

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman
/listinfo/spip-zone-commit

----spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--

♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪.♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪

4

L’unique problème, c’est que même si sur la zone, il y a pas mal de plugins avec une organisation branches/trunk/tags, c’est que le plus gros des zip sont fait à partir du trunk et non d’une branche !

Ce qui finir par faire que les « branches » devienne des sorte de « tags » et qu’il y a peu de vrai tags sur la zone !

https://zone.spip.org/trac/spip-zone/browser/archivelist.txt

L’un des rares plug qui me vienne à l’esprit comme ça qui est assez carré, c’est la « fabrique » de maricmat, qui même si elle n’a pas de « tags », la création du zip est faite à partir de branches.

Franck

De : Gildas Cotomale [mailto:gildas.cotomale@gmail.com]
Envoyé : mardi 6 juin 2017 22:30
À : Debondt Didier p@henix.be
Cc : Spip-Zone Commit spip-zone-commit@rezo.net; SPIP-Zone spip-zone@rezo.net
Objet : Re: [Spip-zone-commit] [SPIP Zone] r104775 -plugins/saisie_liste/trunk

Le 6 juin 2017 à 22:08, Debondt Didier a écrit :

Est-ce que je suis le seul à trouver cela confus à tous les niveaux ?

Ce qu’il faut retenir c’est juste qu’il faut penser à mettre à jour les numéros de version quand on fait des modifications de code.

À aucun moment un numéro de version de plugin ne garantit le code du plugin, c’est quand même un peu idiot…

En fait quand on utilise un système de versionnage de code, chaque « commit » est en soi déjà une version :wink: Les « tags » et les « branches » sont une organisation en plus sur lesquels vont s’appuyer les « releases » (qui sont appelés « versions » ici) pour les utilisateurs.

Et SVP suit la logique des utilisateurs et regarde le numéro de version (release). Et cette information est mise à jour dans un fichier XML de méta-données car les plugins sont distribués par zip (SVP n’a pas à se soucier des « commit » sur Svn ou Git ou autre)

Pour garantir le code, comme tu dis, il faut aller chercher directement dans le système de versionnage du code…

Didier

Le 06/06/17 à 11:22, Ybbet Spip a écrit :

Le 6 juin 2017 à 11:01, Cédric Morin <cedric@yterium.com> a écrit :

J’en profite pour tordre le cou à cette légende urbaine :
la génération des zips ne prends en compte que les date de dernier commit, le changement de z sur la version du plugin ne change RIEN.

Sans doute à l’origine de cette légende le fait que parfois la génération du paquet bloque et un nouveau commit le déclenche, mais il suffirait de commit n’importe quoi dans un fichier readme pour avoir le même résultat.

Le changement de x ou y ou z permet tout simplement à SVP de voir que le plugin a été mise à jour. Cela convient pour des installations du plugin déjà réalisées avant le changement de numéro.

Pour toute nouvelle installation après le changement de numéro (ou même tout simplement un commit), SVP téléchargera la dernière version de l’archive du plugin.

Exemple :

  • Le plugin Toto est à la version 1.2.3. Cette version est disponible depuis le 1er février.

  • M. Dupont a installé ce plugin sur son site le 2 février.

  • L’auteur du plugin Toto a depuis le 3 février apporté quelques correctifs et améliorations à son plugin. Il a fait donc des commits mais n’a pas changé le numéro. Son dernier commit date du 14 février.

  • Mme Martin a installé le plugin Toto le 15 février par SVP.

Dans ce contexte, Mme Martin aura dans la version du 15 février tous les commits de l’auteur du plugin. Choses que n’a pas M. Dupont. Pourtant, tous les deux ont la version 1.2.3 du plugin Toto.

L’auteur du plugin Toto se dit qu’il faut changer le numéro de son plugin. Il commite le 1er mars la version 1.2.4.

M. Dupont et Mme Martin voit le 2 mars qu’il y a une mise à jour du plugin car SVP a détecté la nouvelle version.

Voilà.

:slight_smile:

–
Cédric

spip-zone-commit@rezo.net a écrit :

Author: bystrano@gmx.ch
Date: 2017-06-06 10:01:43 +0200 (Tue, 06 Jun 2017)
New Revision: 104775

Modified:
plugins/saisie_liste/trunk/paquet.xml
Log:
up de z

Contrairement à ce que je pensais, il faut le faire pour déclencher la
génération d’un nouveau zip.

Details: https://zone.spip.org/trac/spip-zone/changeset/104775

Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

----

[spip-zone@rezo.net](mailto:spip-zone@rezo.net) - [http://listes.rezo.net/mailman/listinfo/spip-zone](http://listes.rezo.net/mailman/listinfo/spip-zone)

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

–

http://fr.wikipedia.org/wiki/TOFU_%28Usenet_et_Internet%29
♪♫•¨•.¸¸❤¸¸.•¨•♫♪.♪♫•¨•.¸¸❤¸¸.•¨•♫♪

5

Debondt Didier a écrit :

Est-ce que je suis le seul à trouver cela confus à tous les niveaux ?

À aucun moment un numéro de version de plugin ne garantit le code du
plugin, c'est quand même un peu idiot…

Aucun automatisme ne remplacera ça, sauf à incrémenter automatiquement la version à chaque commit sur un plugin ; mais même là ça perdrait de son sens puisqu'un tel mécanisme ne permet pas de déterminer si c'est une évolution mineure ou majeure.

Par ailleurs, je rappelle que rien n'oblige à créer les zip à partir des trunks.
Une bonne pratique pour assurer une politique de release consistante serait de les créer à partir de tags uniquement.

Au final c'est aux développeurs de gérer ça proprement et selon la politique de versionnage qui leur parait adaptée à leur plugin.

(à titre perso je suis par exemple assez rigide sur un plugin comme bank, beaucoup plus coulant dès que le code n'engage pas de risques fondamentaux et je fais attention à bien versionner toute modif qui modifie la base et nécessite un upgrade)

--
Cédric