Version LTS (Support à Long Terme) de Dolibarr?

Discuter entre Dolibarriens
1

Suite aux échanges dans le fil « le coin de dev de modules » la création d’un fil dédié au sujet d’une version dolibarr « LTS » semble indiqué …

EasyA propose son offre sur la version 14.0 de dolibarr et assure la maintenance à « long terme » durant … années (@pscoffoni ou @aspangaro-Inovea ou autres à vous de détailler) …

De ce fait il semblerait possible (c’est une idée) qu’on décide (nous développeurs) de maintenir nos modules pour:

  • version 14.0 de dolibarr jusqu’en … (année de « fin de vie » de la 14.0-LTS)
  • en complément de la version n-2 … develop comme c’est le cas aujourd’hui

Reste que pour les utilisateurs il faudrait aussi clairement indiquer l’existence de cette version LTS, de son rythme de mise à jour, d’évolutions, date de fin de vie etc. Pour nos clients ça serait un « plus » de savoir qu’ils peuvent se lancer sur une version et ne pas avoir à « forcer les upgrades » pendant X années (et donc former les équipes etc.).

2 « J'aime »
2

Avoir une version LTS me semble prioritaire, ne serais-ce pour le versionning de nos modules.

Actuellement je garantie la compatibilité descendante sur les 3 dernières version de dolibarr soit aujourd’hui la 18, 17 et 16.
Si il y avait une version LTS officielle, je pourrais aussi étendre ma garantie de compatibilité à cette version.
Aujourd’hui d’ailleurs tout mes modules ne sont pas capable de fonctionner sur la 14 à cause d’une évolution des extrafields…

1 « J'aime »
3

Avant de partir sur une LTS il faudrait peut être revoir le rythme de sortie des nouvelles versions.

Je n’ai toujours pas compris la frénésie de sortie de deux versions par an. En plus à chaque nouvelle version on nous précise qu’elle n’est pas réellement stable et qu’il vaut mieux attendre la vXX.0.2 pour faire la mise à jour. Un rythme moins soutenu permettrait de sortir des versions release candidate RC1, RC2… et de sortir ensuite une nouvelle version réellement prête pour être utilisée en prod.

Si on ralentissait le rythme avec une nouvelle version majeure tous les deux ans, et donc une évolution « tranquille » de la version en cours on aurait déjà en quelque sorte une LTS.
Vous avez peut-être remarqué que le second chiffre de chaque version reste toujours calé sur 0

3 « J'aime »
4

@hop je ne sais pas qui vous êtes, votre profil est masqué et donc aucune idée de votre implication / rôle / whatelse dans le projet

« peut être revoir le rythme de sortie des nouvelles versions » est un point de vue mais n’a aucun lien de cause à effet avec le reste, un numéro n’est qu’un numéro, regardez les numéros de versions de chrome, firefox et autres, en fait ça ne veut plus dire grand chose (et je fais partie de ceux qui le regrettent). J’aimais bien l’idée de version majeure . mineure . correctif avec un saut de version majeure lorqu’une « grosse rupture / amélioration » était présentée.

Il existe aussi des numéros de versions en année . mois … façon ubuntu, ça permet à certaines personnes de se représenter si la version utilisée est récente ou pas …

Mais encore une fois ça n’a aucun lien avec l’idée de l’évolution tranquille.

De ce que j’ai compris de la réalité du projet c’est qu’il y a en permanence des choses qui arrivent sur le git, la communauté propose spontanément des améliorations / ajouts / modifications. C’est un vrai projet communautaire, sans « pilote » au sens décisions de ce qu’il faut faire, mais un patron qui endosse le rôle de « mergeur » qui accepte ou refuse les PR c’est tout.

Laurent s’est déjà exprimé sur le sujet du rythme de sortie des versions cherchez dans l’historique vous trouverez le pourquoi :slight_smile:

Une idée que j’essaye de faire avancer serait d’avoir des « responsables de thèmes » un peu comme pour le noyau linux: un responsable du thème « compta » semble spontanément être là: @aspangaro-Inovea … il faudrait voir comment nous pourrions définir les autres thèmes, par exemple avoir un responsable « GED » qui se chargerait de piloter le sous projet de GED, et une fois assemblé proposer une « belle PR » vers le core

Mais ça demande une grosse évolution dans l’organisation du projet, reste encore une fois à savoir qui pourrait assumer de passer quasiment 100% de son temps sur l’organisation d’un thème de dolibarr ?

2 « J'aime »
5

Alors je me suis suffisamment prise la tete depuis des années sur cette c…nerie d’avoir deux versions par an que j’ai abandonnée, aujourd’hui le maintien mes modules sur la version impaire (début d’année) et quand j’ai le temps j’upgrade sur le seconde. Marre de passer mes vacances à devoir tester mes modules sur la beta (et pas la peine de me faire un laius sur les tes de mes modules en continu sur la version en développement, j’ai déjà eu le cas d’un changement de dernière minute qui m’avait obligé à tout revoir…

Par contre si une LTS est réellement mise en place, on pourrait prendre un rythme deux sortie annuelle entre une version mise à jour de la LTS (avec par exemple le chiffre du milieu mis à jour (ex : 14.0.5 qui deviendrait une 14.1.0) pour les évolutions obligatoires et autre détection de faille et une version non LTS

6

Un numéro n’est pas qu’un numéro.
Cela a un impact sur le client final si vous gérez des installations de Dolibarr, à chaque fois qu’un client remarque qu’une nouvelle version existe j’ai droit à question « pourquoi c’est pas mis à jour chez nous ? ».
Et c’est reparti pour une séance d’explications nouvelle version pas stable etc… On m’a déjà demandé si c’était vraiment fiable Dolibarr si les nouvelles versions qui sortent ne sont pas réellement utilisables en prod.

1 « J'aime »
7

Bonjour,

@erics, nos contrats de maintenance impose 5 ans d’intervention sur une version. Nous allons dans 1 an commencé à forcer nos clients sur Easya 2019 (dolibarr 7.0.x) à passer sur du Easya 2024 (dolibarr 18.0.x).

Easya 2020 (dolibarr 10.0.x) > Fin 2025
Easya 2022 (dolibarr 14.0.x) > Fin 2027
Easya 2024 (dolibarr 18.0.x) > Fin 2029

Bonne journée

1 « J'aime »
8

Oui, enfin ce sont VOS contrats, en quoi doivent-ils impacter le versionning de Dolibarr (cela ne devrait-il pas être l’inverse?)

9

Oui, ce sont nos contrats.
Je ne comprends pas ta réflexion sur l’impact sur le versionning de Dolibarr, on n’influence en rien à mon sens. C’est du soft fork, on replug avec la version disponible tous les 2 ans et on maintien durant 5 ans.

Bonne journée,

10

Merci c’était ça … mais je ne voulais pas m’avancer avec des dates foireuses, je n’ai pas la mémoire des chiffres !

Et bien en fait moi je ne vois pas la un problème insoluble: une entité, un groupe (vu qu’on peut facilement « rejoindre » cette démarche il suffit que nos modules soient compatibles avec la version LTS). Donc un groupe fait déjà le boulot, ça serait efficace du point de vue énergie dépensée que de converger vers ce qui est déjà fait non ?

Et je ne vois pas d’impact des contrats de easya sur le versionning. C’est exactement encore une fois comme le noyau linux: à un moment T debian décide de s’appuyer sur le kernel linux version X.Y.Z alors que redhat s’appuie sur une autre version mineure, suse une autre et ainsi de suite.

La nous avons dolibarr 14 qui est choisi par easya pour être « leur » version LTS mais comme easya est super impliqué(e?) dans la vie de dolibarr pourquoi ne pourrions nous pas « embrasser » ce choix et adopter « nous aussi » la 14 comme « LTS jusqu’en 2027 » puis la « 18 LTS 2029 » ?

11

Bonjour
Nous ne sommes pas là pour imposer une version ou une autre ou un rythme.
Pour l’instant c’est ce que nous faisons et libre comme toujours à qui le souhaite de nous suivre ou de proposer ET faire autrement :blush:. Nous resterons à l’écoute et nous adapterons si nécessaire.
Concernant l’échange sur le fonctionnement actuel n-1 n-2 d’un point de vue concret c’est la release de tag et de package qui est concerné.
Rien n’empêche de proposer des fix sur des branches plus anciennes comme nous le proposons. En l’état @eldy les merge regardez l’historique.
Il faut encore imaginer l’organisation et surtout affronter la réalité que le projet Dolibarr ne peux plus avoir un seul PR mergeur car cela le met à mon avis en danger.
Je mélange deux sujets mais ils sont liés. Si une banche est choisie comme LTS il y aura une charge supplémentaire de merge. Et on est déjà en sous effectif pour moi sur ce sujet.

1 « J'aime »
12

Peut-être faudrait-il abandonner le système de versions et réfléchir à un système de rolling release. Cela réduirait drastiquement le nombre de branches.

13

Hello,

+1, c’est à mon avis l’un des gros problèmes actuels.

14

@hop je plussoie le commentaire d’Éric, vos commentaires sont intéressants mais on aimerait bien savoir qui vous êtes :wink:

1 « J'aime »
15

Et que l’on ne se méprenne pas sur mon propos, @eldy fait un boulot colossal :+1:

3 « J'aime »
16

Tout à fait :+1:

17

Les stats ne vont pas dans le sens de cet hypothèse:
Dolibarr a un taux d’intégration de PR de 95% aujourd’hui. Espérer avoir plus de PR mergées, et donc avoir un taux de 98% par exemple est clairement utopique surtout quand on sait que le taux de merge est plutôt de 50% sur les autres projets de taille équivalente (exemple Odoo: 30%, mais 85% pour ERPNext, mesuré en 2022)
Ce qui bloque aujourd’hui l’intégration de plus de merge, c’est l’instabilité que chaque merge génère et la phase de stabilisation qui est nécessaire pour « digérer » une PR d’évolution. Ce temps et cette charge de travail pour stabiliser des évolutions intégrées est exponentielle avec le nombre de PR intégrés. Ainsi, si on release 2 fois moins souvent, le temps et les efforts pour « stabiliser » est multiplié par 4. Vu autrement, pour un résultat identique en terme d’évolution, la charge de travail est multiplié par 2. Ou encore, pour un résultat identique en terme d’évolution et une charge de travail identique, la qualité de stabilisation est divisé par 2 en releasant 2 fois moins souvent.
Aujourd’hui l’intégration de nouvelles PR est actuellement volontairement freiné pour pouvoir digérer les PR intégrés. En effet, le goulot d’étranglement est surtout au niveau du nombre de contributeurs qui « corrigent et stabilisent » les PR intégrés. Rappelons les chiffres, évalués lors d’un ancien devcamp : Sur Dolibarr, pour 1 PR d’évolution intégrée, il faut environ obtenir 2 PR de fix de stabilisation (évaluation 2022 faite sur Odoo: 2.5, sur erpnext: 7)
Hors aujourd’hui le nombre d’évolutions proposés et qui sont intégrés est plus important que le nombre de fix ou de stabilisations (normalisation, sécurisation, …) proposées alors qu’il devrait être de 1 PR sur 3 seulement pour être à l’équilibre.
Bref, il n’y a pas de sous effectif sur le merge (d’ailleurs la charge de travail quand on connait bien l’appli est assez faible) mais un sous effectif sur les Fixeurs, Débuguers et Killer de dettes techniques que j’appelerais avec les initiales, les FDK pour la suite (ceux qui bossent durant une phase beta pour remettre l’application stable et/ou cohérente, corriger les régression, mais aussi durant les phases de dev pour réduire la dette technique par exemple).

Un mergeur peut se remplacer car c’est une tache qui nécessite de la connaissance technique forte, historique et vision anticipative certes, mais peu de mobilisation (scoop: on va quand même essayer une expérimentation de former au metier de mergeur au prochain devcamp !).
Par contre, la où le projet est en risque, c’est le manque de FDK (car il repose sur quelques personnes uniquement et c’est une activité qui nécessite un gros investissement de travail). C’est là que se trouve le « bus factor », sur les FDK (je vous laisse aller voir su wikipedia la définition de Bus Factor). L’idée de releaser plus souvent (rappel: rendre stable une version est exponentiel à la quantité d’évolution de cette version) est la solution prise par beaucoup de projets pour rendre la stabilisation plus facile, jusqu’à pousser le système en « rolling release » mensuelle, ou hebdo par certains. Pour Dolibarr, un rythme mensuel ou même trimestriel est malheureusement trop rapide car il faut laisser le temps à la communauté d’analyser et commenter chaque PR, ce qui ne se fait pas dans un planning non contraint du fait du mode communautaire du projet.
Bref si vous avez des idées pour augmenter le nombre de « FDK », ou inciter des acteurs à se convertir de développeur métier vers FDK, c’est le bienvenu, car c’est la le goulot d’étranglement et là ou le projet est à risque (le problème est que développeur métier se vend aux clients, mais pas FDK). Si on trouve un « truc » pour motiver des acteurs pour assurer ce role en soutien de la poignée de FDK existant (les doigts de la main suffisent à les compter), on fera un gros progrès sur la stabilisation…
« Point de vue perso, car tiré d’expérience perso… »

2 « J'aime »
18

Merci pour les stats et ces explications, cela permet d’avoir une meilleure vision d’ensemble.

En ce qui concerne les FDK j’ai quelques suggestions à faire.

  • Essayer de parrainer ou d’épauler des développeurs nouveaux venus sur le projet Dolibarr, en les accompagnant pour leur première PR par exemple. Tout le mécanisme de github et le fonctionnement d’un projet open source peut être intimidant et freiner la participation des néophytes

  • Le plus long pour fixer un bug c’est souvent de mettre en place la configuration qui permet de le reproduire. On pourrait faciliter le travail des FDK en mettant à disposition des BDD de test pour les différentes versions de Dolibarr. Le FDK n’aurait alors qu’a faire le checkout de version sur laquelle on veut corriger le bug et de restaurer la BDD correspondante.

  • Ensuite améliorer les tags sur les issues github, en précisant les versions de Dolibarr et/ou de php concernées, peut être également préciser si cela concerne l’API et/ou quel module du core. Ou du moins au moins faire ressortir les issues qui nécessitent réelement un fix.

  • Fermer également les issues qui n’en sont pas comme Bug: · Issue #26114 · Dolibarr/dolibarr · GitHub (exemple extrême, mais il y a un certain nombre de sujets ouverts sans intérêt qu’on peut fermer pour nettoyer la liste)

19

Petite suggestion supplémentaire.

Certains projets open source organisent le mois précédent la sortie d’une nouvelle version une période de correction des bugs qui « trainent » en invitant le plus de monde possible à participer. Le but étant de fixer le plus de bugs possibles.

20

Bonjour,

Là où on pourrait grandement améliorer dolibarr, c’est sur les tests E2E, car une grande partie des tests doivent être faits manuellement. Faire des release régulière, et donc faire de l’utilisateur final le testeur, lui donne l’impression que la solution n’est pas stable.

J’ai découvert récemment Jdi-light qui permet de définir les éléments de la page dans un objet et ensuite dans les tests, il ne reste plus qu’à interagir avec les objets.
Dans les exemples, on peut voir la définition d’un formulaire puis la saisie du formulaire se fait simplement via un DTO (exemple).
L’écriture des tests est moins chronophage que du selenium classique.

C’est en java, mais ne demande pas un niveau de connaissance élevé de java.

De plus, la définition pourrait être un artefact java pour permettre aux développeurs de module de l’importer facilement et de faire des tests de leurs modules plus rapidement, car il aurait déjà toute la partie dolibarr défini.

En cas de changement dans l’UI, on modifie la définition de la page et si le comportement ne change pas, pas de changement du test nécessaire.

Personnellement, je pense qu’une LTS n’est pas nécessaire. En revanche, il faudrait réfléchir à une réelle mise en place de dépréciations sur au moins deux versions avec un warning qui indique sur quelle version ce comportement sera supprimé et pas juste un @deprecated sur une fonction et quand il y a un deprecated, mettre la version ou ça ne fonctionnera plus. Si on doit changer le comportement ou la signature d’une fonction, on en crée une nouvelle, on modifie l’ancienne pour qu’elle soit compatible avec l’ancienne.
Concernant les modifications de la base de données, on ne devrait pas changer d’une version à une autre, mais garder les deux dans le même principe des dépréciations et avoir un référentiel de changement d’une version à une autre (avec une colonne pour dire si c’est déprécié ou supprimé)

Comme le dit @hop, un ménage dans les issues GitHub ne ferait pas de mal.

Concernant les PR qui ont besoin d’être validés, on pourrait avoir des issues avec un tag du genre « PR to be tested » ainsi que sa version de sortie et la procédure de test, qui permettrait au non-développeurs de faire des retours. Derrière, le travail des développeurs est largement diminué.

Pour ça, il faudrait une instance de dolibarr mise à jour régulièrement, pour que les testeurs puissent facilement tester sans avoir de compétence particulière.

1 « J'aime »