Ce n’est pas moi qui peut accepter ou refuser. C’est ceux qui ont la capacité à s’engager dans une telle démarche qui accepteront ou refuserons de la mener.
De mon côté, je vois l’initiative bienvenu, mais je préfère me limiter à mes compétences de valideur/mergeur de PR (bref au contrôle qualité pour faire simple) et laisser les acteurs qui peuvent s’engager se prononcer sur leur dispo et agir… (PS: Mieux vaut utiliser un canal chat type what’s app, signal… pour les messages qui attente un réponse rapide, car mes mails je peux rester 2 à 3 semaines sans les lire :-).
Dans la mesure ou actuellement toutes les branches sont « ouvertes à faire du LTS » (que l’on fait déjà plus ou moins de manière officieuse), je ne vois pas d’incompatibilité à mobiliser des gens qui essaierait d’alimenter encore plus ces LTS avec un engagement plus fort pour avoir une position plus officielle…
Par contre, je pense que la règle de nommage de version n’a pas besoin d’être complexifiée. Si on maintient une branche « plus longtemps » avec engagement d’un acteur sur une durée, elle n’a pas de raison d’avoir une autre numérotation dans ces chiffres. Le flag « LTS x ans » peut suffir, si il y a une démarche d’engagement sur la durée du LTS, pour marquer que c’est du LTS avec garantie. Le plus dur, va être de trouver qui s’engage sur cette garantie. Le seul fait d’avoir un engagement me laisse penser qu’il ne peut se faire que dans une démarche contruactualisée, donc commerciale d’un ou n acteurs mais difficile par des commiteurs bénévoles.
Par contre, il y a un point qui ne peut se négocier si cela doit intégrer les branches officielles: Une LTS doit se limiter à de la maintenance et non à de l’ajout de nouveautés (sauf backport pour raison légale, car bloquant). Cette règle est actuellement appliquée dans le maintien actuelle des vieilles versions, et doit le rester. Sinon, ce n’est plus du LTS mais de la « double évolution séparée », qu’on appelle fork, ce qui est tout à fait possible aussi et se fait déjà. On peut imaginer un fork nommé DolibarrLTS mais je n’aurais pas la disponibilité pour assurer le role de contrôle qualité de mon côté sur ces forks. Ma préférence va à la première solution (PR d’acteurs engagés qui soumettent, voir merge les fix et fix uniquement sur la base des bonnes pratiques de fix, soit « le minimum et juste le minimum pour débloquer » plutôt qu’à la seconde qui a juste l’avantage d’être plus permissive mais dispersives. De telles initiatives existent déjà d’ailleurs sous forme commerciale. Mais une fois encore, dès lors qu’on parle d’initiative communautaire, ce n’est pas ma préférence qui décide, mais ceux qui font (ou feront) sont disponible à faire…
Merci @eldy je pense en fait que bon nombre de lecteurs étaient restés coincés sur une vue négative.
Donc @toutes et tous, qui est prêt pour proposer officiellement dolibarr 18 LTS ? tel que:
a) proposé sur le wiki/decidim
b) en restant sur la numérotation basique simple (donc dans les .1 .2 .3 intermédiaires), je rejoint complètement @eldy sur ce point
c) en étant clairement que sur de la maintenance corrective
Nous terminons un formulaire sur le decidim avec @pscoffoni et ensuite il faudra aller vous y inscrire pour la suite
Au risque de faire le mono-maniaque ça me semble vraiment être un point central de la proposition d’avoir une version LTS de dolibarr … et nous aurions aimés lancer cette LTS avec justement la sortie de la 19.
La version 18.0.x passe « LTS » lors de la sortie de la 19
Et sur les objets officiels de comm du projet dolibarr seraient alors présentés DEUX versions:
18.0.x LTS
19.0.0 version « toutes nouveautés »
six mois plus tard sur les mêmes objets de communication:
Chez OPEN-DSI, nous disposons d’une version de production en v7 (amélioré avec de nombreux modules), qualifié de LTS car nous allons corriger les bugs jusqu’en 2022 dessus, ce n’est pas un fork mais cette version est la meilleure pour le moment niveau stabilité et mise à niveau des modules même si la v9 nous fait de l’œil sur bien des points. Par contre sur notre version, la compta de la v10 est présente via un backport afin d’avoir les dernières nouveautés sur ce sujet qui me tient à cœur.
Sinon, bah il faudrait voir avec Laurent et l’invité à s’exprimer sur le sujet sur le forum mais je connais son point de vue.
La gestion du code ne dépendant pas de l’association…
@alex
Merci pour ta réponse, nous maintenons aussi une version 7 « custom » pour ne pas dire lts de notre côté également améliorée de quelques trucs mais pas de backport de la compta
Je cherche à ouvrir une discussion car une lts n’est pas sans effets collatéraux sur l’écosystème Dolibzrr.
@+
Je considère uniquement les versions impaires de Dolibarr pour qualifier mes modules mais je vais sans doute devoir faire une exception pour la V10 car le versionning passe sur deux chiffres…
Honnêtement le rythme de sortie des versions est bien trop élevé pour un CRM…
Une version majeur par an ça suffit.
Et des LTS toutes les deux versions (les impaires pour faire plaisir à Charlie!)
pour ceux utilisant stripe via dolibarr, seule la version 10 sera utilisable au 14 septembre 2019 suite à la mise en place du SCA pour tous les paiements en Europe.
Donc le choix de la LTS doit être fait judicieusement sur une version conçue pour et permettant un vrai support long.
>Sinon, bah il faudrait voir avec Laurent et l’invité à s’exprimer sur le sujet sur le forum mais je connais son point de vue.
Et quel est-il, par curiosité intellectuelle ?
Je suis également pour la stabilité et le principe d’une LTS… Toute entreprise est pour le principe d’une LTS… Mais j’aime bien comprendre Et là je ne comprends pas cette course aux numéros, qui n’existait pas quand j’ai quitté la communauté en 2012/2013…
En ralentissant les sorties à une par an (ou sinon majeure / mineure, c’est un peu le cas aujourd’hui d’ailleurs, j’estime que les versions paires sont moins bonnes, par ex v10.04 / v10.10), cela réglerai le problème d’une LTS en doublant le temps de correction soit 3 ans mais c’est pour montrer le dynamisme du projet. Rien de ne sert de passer tout de suite à une nouvelle branche car on est sur un ERP ou sinon par un partenaire adapté pour éviter les problèmes.
Pour la folie des numéros, c’est juste qu’on a trouvé plus sympa le passage à des numéros complets à chaque version depuis la v4 (avant 3.9, 3.8, etc), c’est plus compréhensible pour tout le monde même sur le dolistore
Bonjour,
Je n’ai pas vraiment de besoin de LTS pour mon usage, mais je ne pense pas qu’une version maintenue 1 an 1/2 soit une version LTS.
Les avis ont été exprimés, ce qui est souhaité est une version soutenue 4 à 5 ans. Ça ne veut pas dire que toutes les versions intermédiaires sont soutenues. Ceci est particulièrement demandé par ceux qui proposent des modules complémentaires.
Et je ne pense pas que la question soit celle des moyens. Si on maintient l’actuelle, la précédente et la LTS, c’est le même boulot, à la nuance près que les adaptations seront peut être plus délicates sur le code ancien. Et moins de boulot si on maintient l’actuelle et la LTS uniquement.
Bonjour,
Il faut pour maintenir une banche un « mainteneur » qui soit en mesure de créer des release sur la branche LTS. Il faut que quelqu’un candidate au rôle de Jedi
Et « s’engage » à piloter le processus de release.
Rappel de la synthèse effectué sur le sujet en devcamp (@defrance peut-être pas si inutile que cela )
Un de nos dev va candidater à son retour de congés semaine prochaine
Et là je ne comprends pas cette course aux numéros, qui n’existait pas quand j’ai quitté la communauté en 2012/2013…
)
