@erics, merci pour ce retour documenté !
Le principe de la LTS en 2023, décidé au DevCamp, a été validé, et encadré par un processus de validation, mais quand même avec un gout de “on verra si ça marche”.
C’était une demande forte de la communauté des intégrateurs, permettant d’assurer un service stable à leurs clients.
L’expérience a montré que c’était possible. Avec du temps, tout est possible, mais du côté des mergeurs LTS, comme du côté d’@eldy, cela a impliqué une charge de travail importante, qui n’était pas facilement estimable au démarrage de l’initiative, elle a été absorbée, mais pas couverte (€) directement.
À partir d’un moment (on est en 2026), réussir à merger la 18 dans 19 puis 20 et etc, sur 5 versions, ça commence à en faire des conflits de code à traiter.
Dans d’autre projet open source (dont le kernel linux, mais aussi d’autre ERP Open source), on corrige dans la branche “develop” (si le bug existe toujours) et si nécessaire ont fait d’autres PR pour transposer (cherry pick) là où c’est possible dans les versions d’avant. Ce n’est pas la stratégie du projet Dolibarr. Tant mieux, ou pas, mais au moins la 18.0 est une version qui a eu la plus longue vie en support communautaire.
Retour d’expérience :
Je découvre que les 3 PR citées dans la page Wiki sont des PR de Scopen.
Des clients nous ont remonté ces “anomalies”, dans une version 20 (peut-être même 21), mais nous avons joué le jeu de la LTS: si le bug existe en LTS (18.0), il faut proposer un fix en LTS (18.0).
Même si les 2 PR en attentes ne seront probablement jamais mergées dans leurs formes actuelles, les cas décrits sont des cas réels et reproductibles. Si Scopen avait pris le parti de faire les PR en develop, il y a plus chances qu’elles auraient été mergées, donc que les anomalies détectées auraient été corrigées. Le constat est mitigé pour ces exemples… Ici aussi, c’est une histoire d’investissement, du temps à prendre pour tous les acteurs de la chaine.
