Dans le cadre de la migration vers duniter-v2s et plus particulièrement de la construction des paquets .deb et Yunohost, la question de la numérotation et du nom des exécutables de la v2 se pose.
Typiquement, une machine faisant déjà tourner duniter v1 grâce à un .deb va se retrouver avec un avertissement dpkg: avertissement: dégradation (« downgrade ») de duniter depuis 1.8.7 vers 0.8.0-1 lors de la mise à jour, si l’on conserve le nom et la version des paquets actuels de duniter-v2s.
Plusieurs solutions sont envisageables :
Nommer les binaires et les paquets autrement (par exemple duniter2, duniter-v2s, etc.), ce qui a pour avantage de permettre une cohabitation facile entre les versions v1 et v2, les binaires et paquets étant séparés.
Garder le nom duniter mais commencer directement en version 2.0, ce qui a pour avantage de rendre la mise à jour quasi invisible, mais qui ne permettra pas une cohabitation aisée entre une v1 et une v2, les binaires et paquets étant remplacés.
Changement de nom : duniter2 & Préservation de la version : 0.8.0
Changement de nom : duniter-v2s & Préservation de la version : 0.8.0
Préservation du nom : duniter & Changement de numérotation : 2.0.0
La convention pour le SemVer en Rust est de passer en >=1.0.0 quand il n’y aura plus trop de changements cassants et que la stabilité sera assurée par une équipe réactive. Ça correspond à ce qu’on veut pour la migration. De ce point de vue il semble cohérent de passer la crate en 2.0.0 un peu avant la migration.
Est-il possible de migrer automatiquement la config d’une install Debian ? Ou est-ce que lors de la màj on peut juste être prévenu que l’ancienne config n’est plus compatible et qu’il faut la refaire (trousseau, nom du nœud, adresses publiques, miroir/forgeron/archive, etc.) ?
Les configurations ne sont pas actuellement compatibles, mais il est possible d’avertir l’utilisateur lors de la mise à jour qu’il devra reconfigurer.
Il faut également réfléchir à la gestion des anciens fichiers de configuration ; il est envisageable d’ajouter un script pré-installation au fichier .deb pour déplacer/supprimer les anciens fichiers de configuration et ne pas les laisser encombrer le système sans être gérés par un paquet.
Je suis pour duniter2 car v2s m’agace depuis le début.
v → ben on sait que c’est une version donc on peut omettre le “v”
s → ben on sait que c’est substrate nous et ça risque pas de changer donc on peut omettre le “v”
Duniter2 permet de garder v1 et v2 sur le même poste (on a dit qu’on laissait aux nostalgique la possibilité de rester en v1.
Même @poka est d’accord pour laisser vivre la V1 (quelques heures… ).
Selon la manière dont la migration est faite il pourrait ne pas être nécessaire d’avoir les paquets des deux versions en simultané.
À la date de la migration les paquets pourraient rester en v1. Un seul nœud v2 (lancé par un dev) ferait les premiers blocs, rapidement rejoint par d’autres devs (qui auraient une version compilée maison, une release sans paquet ou un paquet non encore publié). Dès que le petit réseau est stable, les paquets grand public peuvent être publiés.
Comme il y aura toujours des gens ici qui ne passent pas par les paquets, et qu’un petit réseau suffirait pendant quelques jours, ça me semble moins critique que l’organisation des clients pour basculer au bon moment.
À moins que V2 doive être installable facilement pour la ĞTest ?
Pas plus de quelques heures oui.
Moi c’est pas pour ça, c’est parceque j’aime bien v2s, pour moi c’est un écosystème.
v2s se suffit à lui meme, pas besoin de préciser Duniter, c’est comme si le numéro de version devenait la marque, ou le label, d’un écosystème technique.
… Et aussi parceque j’aime voter à contre courant.
C’est pour ça que j’ai voté Chirac Dimanche.
Je pense que ce serait bien qu’un max de forgerons s’essaye à la V2 avant la bascule.
Donc une version installable simplement, ce serait bien. Ou alors, on cherche à trier sur les capacités technique des forgerons.
@joss.rendall qui départage le résultat par son vote en faveur de duniter2, incroyable retournement de situation, s’écartant ainsi de la situation de départ ! Les jeux sont toujours ouverts.
@italpaola qui change la donne, sur les appuis de @Maaltir, pour asseoir duniter en favori de ce sondage ! Retour en force du champion historique, mais duniter-v2s a-t-il encore une chance ? Comment réagira le camp du bien ? C’est la question qui est sur toutes les lèvres !
En vrai si on applique SemVer garder le nom et le changement de version a 2.0 semble logique. C’est plus l’ancien qu’il faudrait renommer en “duniter-legacy” car personne ici n’a envie de le maintenir ni de gérer 2 version en parallèle.
Ou duniter2 version 2.0.0 pour faciliter la transition, puis repasser sur duniter version 2.0.0 au bout d’un ou deux ans parce que pas glop de garder ce 2 dans le nom (qui a connu apache1 ?).
Ok, on a une majorité pour préserver le nom duniter. En pratique voilà comme on pourrait faire :
garder duniter2 provisoirement pour faciliter les tests pendant l’alpha
renommer duniter en duniter-legacy (ou autre) dans une “1.99” éventuellement avec un mécanisme antifork (à détailler)
renommer duniter2 en duniter avant la migration pour prendre la place du legacy avec un numéro de client >= 2.0
Comme ça on facilite la vie aux forgerons qui manipuleront les deux sur la même machine pendant les phases de tests et on reste propre pour la production.
Je pense que cette stratégie en deux temps va être particulièrement utile si on veut avoir des forgerons Yunohost v2 sans perdre les forgerons Yunohost v1 ! Cf le message de @tatinettebPaquet Yunohost pour Duniter - #2 by tatinetteb. Je ne sais pas si c’est raisonnable d’essayer de boucler ça avant la fin de contrat de @bgallois le 10 juillet ou s’il vaut mieux reprendre à la rentrée en septembre (sous réserve d’avoir la troisième tranche du financement ADEME avec @AxiomTeam).
).
