Les problèmes que STEP et SVP ont rencontré autour ces numéros me fait dire que ce n'est pas ainsi qu'il faut procéder: au lieu d'alourdir le code qui tourne souvent, il faut développer un script de migration pour rationnaliser une fois pour toutes les infos données dans plugin.xml. Ainsi le noyau de SPIP restera léger et facilement compréhensible. Pour les versions de SPIP, on a fini par adopter la notation x.y.z, il faut que les plugins y passent aussi. Je peux rajouter dans l'utilitaire "plugin2paquet" au besoin.
Je suppose que tu veux dire qu'on a fini par évacuer x.y.z au profit d'un entier ?
Perso je m'en mords les doigts à chaque fois qu'on doit faire des upgrade de base, et je continue a penser que c'était une belle erreur.
Ce qui est fait est fait sur SPIP, mais je suis absolument contre généraliser cette numérotation purement temporelle qui n'a aucun sens (d'autant plus quand on sort de SVN qui était le seul repère de cette numérotation entière incrémentale) et est complètement handicapante dans la gestion de versions bases pour des branches parallèles.
Et contrairement au noyau de SPIP où l'on peut alléguer qu'on ne gère pas plusieurs branches à la fois (ce que le passé a montré comme faux),
cette hypothèse est complètement abusive sur les plugins dont tu ne maitrise pas les cycles de développement,
et qu'on ne saurait imposer.
Pour les versions de SPIP, on a fini par adopter la notation x.y.z, il faut que les plugins y passent aussi.
Je suppose que tu veux dire qu'on a fini par évacuer x.y.z au profit d'un entier ?
Oui c'est ce que je voulais dire, mais un problème similaire se pose pour ça.
Perso je m'en mords les doigts à chaque fois qu'on doit faire des upgrade de base, et je continue a penser que c'était une belle erreur.
C'est une discipline qui impose de réfléchir aux évolutions ultérieures avant de faire une modif en base, modif qui impliquerait un fork de la base à terme, autrement dit ne pouvoir basculer sur un changement de numéro majeur une fois le fork de numéro mineur emprunté par la base.
Dans le code de inc/plugins, j'ai justement trouvé des mentions des valeurs de metas de la 1.9.3, celle qui n'est jamais sortie, qui ralentissent et complexifient le code faute d'avoir à l'époque un numéro entier qui aurait forcé une synchronisation de la représentation des bases dans toutes les branches de SPIP.
Alors je le répète: plutôt que de complexifier et ralentir le noyau, il faut restreindre les possibiilités de fork des représentations, et écrire des scripts de migration pour les cas dont on il faut admettre aujourd'hui qu'on aurait pas dû les laisser s'écrire. C'est évidemment moins glorieux que d'ajouter la p+unième micro-fonctionnalité à SPIP, mais c'est infiniment plus utile sur le long terme.
Ça veut dire que tu aimerais que <version>3.0.3</version> dans un plugin disparaisse au profit de <version>303</version> ?
Je ne vois pas vraiment ce que ça change pour les forks, sinon de s'éloigner d'une nomenclature assez admise pour les logiciels, à savoir, l'écriture à 3 numéros.
Autrement dit, cela sous-tend que l'évolution du logiciel ne doit plus relever que d'un plan établi à l'avance, et duquel il n'est plus permis de déroger ?
Que faire une modification en base d'une version en production n'est plus autorisé à partir de l'instant où il existe une version plus plus récente du plugin ?
On interdit désormais a quiconque de découvrir un bug qui nécessite pour sa correction un upgrade de base, si ce n'est pas la dernière version du plugin ?
Je suis désolé, mais dans le monde réel on est obligé de faire tourner des sites et des applications
avec des versions de SPIP et de plugins qui ne sont pas toujours les dernières versions.
Et dans ce monde réel on rencontre des bugs non planifiés, et la réponse "Il faut mettre à jour tout votre site pour corriger ce bug" n'est tous simplement pas admissible.
Interdire de gérer plusieurs branches qui se matérialisent par des numérotation mineure et majeure de base est tout simplement illusoire.
Tu peux refuser de gérer ça dans SPIP, et dans ce cas on continuera à le gérer à la main dans les plugins.
Nier la réalité ne l'empêche pas d'exister.
La réalité c'est que la solution que tu proposes est un pis-aller qui envoient les utilisateurs dans le mur: avec ta méthode, il va y avoir une combinatoire ingérable des versions de chaque groupes de tables de plugin, car l'assurance ne pourra pas être donné que chacune de ces évolutions est compatibles avec toutes les autres. C'est toi qui nie cette réalité car elle ne sera perceptible que dans le futur.
Mais ce n'est pas la peine de discuter de ce point précis, parce que le problème est plus général: faut-il réfléchir et discuter des conséquences à long terme de ce qu'on fait ou non. A chacun de chosir.
Tout à fait. Je n'ai pas dit que c'était un fonctionnement privilégié ni une habitude. Juste que c'est un mal parfois nécessaire, qui pose d'autres problèmes derrière, certes.
En numérotant en entier uniquement, on s'interdit toute possibilité de ce type.
J'ai en tête un exemple concret vécu sur le plugin forms&tables qui utilisait un champ SQL nommé 'schema'
Manque de chance, à partir d'une version donnée de mySQL, schema est devenu un mot réservé qui empêchait les tables de se créer.
J'ai du, bien malgré moi, aller corriger la version en cours (pour SPIP 1.9), mais également la version antérieure du plugin (enfin de l'espèce de plugin pour SPIP 1.8...) qui sinon ne fonctionnaient plus du tout.
Cela a posé bien évidemment des problèmes dans le flot des upgrade selon le chemin qui avait été emprunté, et je m'en serais bien passé.
Mais ça aurait été encore bien pire dans un tel scenario de devoir utiliser sur une ancienne version du plugin un numéro de version base entier postérieur à celui alors en vigueur sur la version récente.
Cet exemple est d'autant plus éclairant que le choix du nommage initial de ce champ était hérité du travail réalisé par Antoine quelques années auparavant.
Au final :
- le changement est intervenu de l'extérieur, sans que j'ai pu l'anticiper
- il m'a bien fallu disposer d'une solution pour rétablir le fonctionnement du plugin
- je n'ai même pas eu le luxe de pouvoir prévoir d'appeler mon champ autrement car j'ai hérité d'un existant avec ses qualités et ses défauts
Prévoir, c'est aussi prévoir qu'on ne peut pas tout anticiper, et se garder une marge de manoeuvre pour gérer les imprévus.
Ce que la numérotation entière ne permet pas, sauf à laisser des trous dans la numérotation pour "simuler" une numérotation par branche.
Réfléchir et discuter d'un futur, ça n'a jamais empêché qu'un autre se produise.
Conserver la nomenclature largement usitée du numéro de version sur trois nombres (et non chiffres, on l'oublie trop souvent) me semble nécessaire, et devrait même peut-être faire l'objet d'une doc expliquant le rôle de chacun de ces nombres.
Un exemple précis peut avoir valeur de généralité si on extrapole.
En extrapolant l'exemple, je retiens que ça répond à ta question : oui on peut essayer de réfléchir aux conséquences à long terme sauf que très régulièrement des changements proviennent soit de l'extérieur, soit d'un existant qu'on ne veut pas reprendre à zéro : c'est ça la réalité. Et ça on ne peut pas le prévoir.
Aller pour le fun, je renvoie sur ce thème à :
Jacques Ellul - Le bluff technologique
Première partie : l'incertitude
Chapitre II : L'imprévisibilité