Pour quel raison avoir changé de préfix ?
- parce que ce sont deux squelettes vraiment différent ? si tel est le cas, ils devraient avoir des noms différents, et pas juste des numero de version, et on devrait créer des rubriques différentes sur contrib + tu devrais expliquer dans l'article le pourquoi du changement
- parceque tu voulais mettre de la cohérence au niveau des nomenclatures? Mais dans ce cas, tu sais que
1. Tu casse la possibilité d'une recherche de mis à jour par SVP
2. Tu casse les éventuels appel de dépendance
En fonction de la réponse à la question du pourquoi du changement de préfixe, on pourra trouver la bonne solution :
- modifier retrospectivement les tags sur les vieilles version en changeant le préfixe (pas terrible, mais faisable)
- revenir pour la nouvelle version à l'ancien préfixe
- créer une rubrique à part pour la nouvelle version.
Ces changements de préfixe sont une plaie, je l’ai déjà dit et répété maintes fois.
Le préfixe c’est juste un id on se fout qu’il soit beau, lisible avec des underscores (pour qu’on ne sache plus où est le préfixe et le reste du nom de fonction ou de fichiers)...
Donc de grâce stop !
Pour quel raison avoir changé de préfix ?
- parce que ce sont deux squelettes vraiment différent ? si tel est le cas, ils devraient avoir des noms différents, et pas juste des numero de version, et on devrait créer des rubriques différentes sur contrib + tu devrais expliquer dans l'article le pourquoi du changement
- parceque tu voulais mettre de la cohérence au niveau des nomenclatures? Mais dans ce cas, tu sais que
1. Tu casse la possibilité d'une recherche de mis à jour par SVP
2. Tu casse les éventuels appel de dépendance
Et dans Contrib on va choisir une rubrique (on en fera pas deux) pour le même squelette.
En fonction de la réponse à la question du pourquoi du changement de préfixe, on pourra trouver la bonne solution :
- revenir pour la nouvelle version à l'ancien préfixe
Oui, s’il vous plait et me le dire afin que j’adapte la rubrique sur Contrib si elle existe.
Pour quel raison avoir changé de préfix ?
- parce que ce sont deux squelettes vraiment différent ? si tel est le cas, ils devraient avoir des noms différents, et pas juste des numero de version, et on devrait créer des rubriques différentes sur contrib + tu devrais expliquer dans l'article le pourquoi du changement
- parceque tu voulais mettre de la cohérence au niveau des nomenclatures? Mais dans ce cas, tu sais que
1. Tu casse la possibilité d'une recherche de mis à jour par SVP
2. Tu casse les éventuels appel de dépendance
L'erreur a sans doute été d'importer la V2 telle quelle dans la forge SPIP pensant que je pourrais partir de cette base pour la faire évoluer et garder une certaine compatibilité. Elle n'est plus développée depuis 2017, n'est pas compatible SPIP 3.2 et n'a rien de commun avec la V3.
C'était au tout début de la mise en place de la forge que j'avais ce projet et l'idée était de l'intégrer dans cette dynamique (pour tester, participer...). A ce moment là, il me semble que l'ancien plugin n'était ni zippé, ni sur plugins.spip.net et qu'il n'y avait qu'un lien dans la doc vers le framagit d'origine. Donc je ne me suis pas trop posé de question...
En fonction de la réponse à la question du pourquoi du changement de préfixe, on pourra trouver la bonne solution :
- modifier retrospectivement les tags sur les vieilles version en changeant le préfixe (pas terrible, mais faisable)
- revenir pour la nouvelle version à l'ancien préfixe
- créer une rubrique à part pour la nouvelle version.
Pour la cohérence avec les autres plugins html5up (et parce que la V2 n'est ni maintenue, ni compatible avec SPIP 3.2), je garderais bien le préfixe html5up_hyperspace mais est-ce que c'est possible en gardant les 2 docs, par ex en "débranchant" la V2 de la forge ? (je tente hein je ne maitrise pas les aspects techniques derrière tout ça)
Ou en supprimant la V2 de la forge et en mettant un zip en dur sur la doc ? (j'imagine que c'est difficilement faisable)
Si pas de solution ou trop complexe/chronophage, je ferai la modif pour repasser sur l'ancien préfixe.
je viens de regarder. Il s'avère effectivement que les anciennes versions (< v2) et autre d'hyperspace (prefixe hyperspace) n'existent via svp que depuis le débardeur. Donc depuis peu. Les tags ont été importé en même temps que l'import framagit.
Dans ces ces conditions, il ne me paraît pas totalement aberrant de faire un "retour arrière" pour avoir des prefixes uniforme.
À savoir en 4 étapes:
1. suppression des tags et des zip depuis le débardeur
2. création de version v2 avec le prefixe html5_hyperspace depuis l'historique + pointage vers la bonne version de doc (je peux m'occuper de cela)
3. republie des tags et debardeur prendra le relai
4. modif du préfixe associé à la rubrique + nettoyage de l'article v2 existant
A noter que nous avons les droits de l'auteur originel de faire ce qu'on veut.
Si les anciennes versions sont totalement incompatibles je suis pas sur qu’il soit pertinent de renommer le prefixe, c’est un nid à emmerdes.
J’en veux pour preuve le cas contraire où la v2 de spipr-dist conserve le même prefixe que la v1 et je le regrette déjà : SVP propose la mise à jour, les gens cliquent et leur site est tout cassé, ils s’en sortent pas et ils galèrent à revenir en arrière car rien n’est prévu pour ça...
Je pense que là il faut juste supprimer les tags de l’ancienne version.
Et faut être un peu souple avec les règles.
Oui c’est mieux en règle générale de pas changer de préfixe, et oui ça complique des choses quand on le fait.
Mais c’est parfois bien pire de conserver un prefixe artificiellement alors que le code n’a rien a voir, l’historique technique non plus, et que rien n’est compatible…
Quand à revenir en arrière a posteriori pour remettre un même prefixe alors que ça va générer des emmerdes, on frise le masochisme (amha)
Si les anciennes versions sont totalement incompatibles je suis pas sur qu’il soit pertinent de renommer le prefixe, c’est un nid à emmerdes.
J’en veux pour preuve le cas contraire où la v2 de spipr-dist conserve le même prefixe que la v1 et je le regrette déjà : SVP propose la mise à jour, les gens cliquent et leur site est tout cassé, ils s’en sortent pas et ils galèrent à revenir en arrière car rien n’est prévu pour ça...
Oui mais là on est dans un cas différent.
Si tout est incompatible on peut dire que c’est bien deux plugins différents.
On devrait même les appeler différemment comme on a fait pour Sarka-SPIP (sarkaspip) et Sarka-SPIP Reloaded (sarkaspipr)
Je pense que là il faut juste supprimer les tags de l’ancienne version.
Oui, c’est le plus simple.
Surtout que contrairement au cas que tu cites le renommage était plus « cosmétique ».
Et faut être un peu souple avec les règles.
Oui c’est mieux en règle générale de pas changer de préfixe, et oui ça complique des choses quand on le fait.
Mais c’est parfois bien pire de conserver un prefixe artificiellement alors que le code n’a rien a voir, l’historique technique non plus, et que rien n’est compatible…
Moi je veux bien être souple et tout ce qu’on veut.
Mais je vous laisserez alors gérer la cohérence d’ensemble car c’est trop chronophage quand personne n’y met du sien et j’ai donné avec Contrib.
oui effectivement j'ai eu le même ennui sur spipr-dist tu fais bien de souligner ca.
Si on supprime les tags des anciennes versions, cela veut dire qu'on cesse de la supporter/distribuer officiellement et cela aurait du sens à ce moment là de dépublier l'article sur contrib.
le retour en arrière aurait pour moi du sens dans la mesure où la distribution svp est récente. Mais tu as raison, c'est difficile de mesure exactement les potentielles implications. Donc oublions cela.
Donc réflexion faite, et vu qu'on a l'accord de l'auteur originel pour faire ce qu'on veut du plugin, ma proposition serait la suivante
1. Dépublication des tags des veilles versions (Eric et Cédric sont ok) + du tag v0.3.2 qui en réalité pointe sur la v3.0.2 (en passant : controle de cohérence à prévoir peut être au niveau du débardeur ?)
2. Depublication de l'article de la veille version (a priori cela a du sens)
3. Modification de la rubrique sur contrib pour affecter le bon prefixe
Si on supprime les tags des anciennes versions, cela veut dire qu'on cesse de la supporter/distribuer officiellement et cela aurait du sens à ce moment là de dépublier l'article sur contrib.
On ne peut pas simplement laisser le zip de la dernière version pour conserver la doc en ligne ?
En effet si le système de gestion avec débardeur et git tag n'est pas adapté à des situations marginales,
ça ne devrait empêcher de faire autrement.
Ça peut être utile d'avoir ce zip en dehors de tout systeme de tag et mise à jour.
Le zip n'est alors pas un rouage de la machinerie générale de release et mise à disposition,
mais un document associé à un article, jouant le rôle d'une annexe dans une documentation historique.
Si on supprime les tags des anciennes versions, cela veut dire qu'on cesse de la supporter/distribuer officiellement et cela aurait du sens à ce moment là de dépublier l'article sur contrib.
On ne peut pas simplement laisser le zip de la dernière version pour conserver la doc en ligne ?
oui on pourrait effectivement, reste la question du mechanisme d'archivage pour indiquer clairement les choses
J’en veux pour preuve le cas contraire où la v2 de spipr-dist conserve le même prefixe que la v1 et je le regrette déjà : SVP propose la mise à jour, les gens cliquent et leur site est tout cassé, ils s’en sortent pas et ils galèrent à revenir en arrière car rien n’est prévu pour ça...
Renommage du préfix + du plugin + création d'une nouvelle rubrique dans contrib (en tout cas c'est comme cela que je vois les choses, mais Eric a peut être une autre vision)
Moi pige pas cette méthode si c'est à suivre à l'infini et pas un truc temporaire. Ça fait des années maintenant qu'on dit qu'on doit aller dans le sens de Semver, et que dès que possible on doit suivre les méthodes employées partout ailleurs.
Or le principe c'est que le numéro X sert *très précisément* à cela : dire que cette version majeure n'est PAS assurée compatible avec la précédente.
Et nous on doit bidouiller à dire que c'est des projets différents uniquement parce que notre outil en interne ne gère pas bien Semver depuis toutes ces années où on dit pourtant qu'on doit le suivre. C'est-à-dire que notre interface (SVP surtout) ne bloque pas par défaut le saut à la version majeure suivante, et ne prévient pas de manière hyper claire que cette version suivante est un numéro majeur différent ("Attention" etc). Ce qui aboutit à l'exemple donné pour spipr avec les gens en galère. Il me semble que la solution pérenne c'est bien de suivre Semver, et faire un ticket SVP pour décrire ça et prévoir de modifier son ergonomie.
bon, en attendant que la typologie de l'archivage soit fait :
- j'ai supprimé les vieux tags, et j'ai créé un tag pour la v3.0.3
- j'ai mis la doc en ligne de la v2 comme archivée
- j'ai publié pour demain la v3.0.3
Jean Marie deux remarques :
- je t'invite à cloner à neuf ton dépot, histoire de l'avoir sans les tags que j'ai supprimé et de pas les rebalancer par erreur
- n'oublie pas quand tu juge qu'une version peut être publié de basculer de l'etat dev à au moins l'etat test
je ne maitrise pas les aspects techniques derrière tout ça)