Bonjour à tous !
Pour information, la première version LTS de Dolibarr est sortie.
LTS => Long-term support — Wikipédia, cette version/branche devrait être maintenue jusqu’en 2028 (soit 5 ans depuis la sortie en 2023 de la v18).
Il s’agit de la version V18.0.7
Téléchargement ici : Dolibarr ERP - CRM - Browse Files at SourceForge.net
Grand merci à l’équipe de développement !
@+
Bonjour,
pas de tag ni de release sur github pour la 18.0.7, difficile de faire une mise à jour sans ça.
Salut @Beers
Oui effectivement, uniquement disponible sur sourceforge. Pas trouvé sur Github, ni une branche séparée.
@+
Bonjour 
Très bonne nouvelle une LTS !
Merci
Bonjour à tous
Est-ce qu’un tag ou une release sur github est prévue ?
Ça permettrait aussi de consulter un changelog.
Bonsoir,
cette première LTS est le fruit d’un long process d’apprentissage auquel nous nous sommes soumis (lionel de easya et moi-même).
sauf erreur de ma part jusqu’à présent le process permettant de créer une release de dolibarr était uniquement réalisé par @eldy et notre implication dans la création d’une version LTS vise à solidifier ce savoir faire en étant plusieurs à savoir faire et à « pouvoir faire ».
nous avons pris des notes qui sont publiées sur le wiki LTS DEV NOTES — Dolibarr ERP CRM Wiki
et concernant la publication de cette version 18.0.7 @Philazerty a été plus rapide que nous : nous avons suivi le process de publication et attendions la validation de @eldy que les fichiers étaient bien comme il faut sur sourceforge avant de passer à la toute dernière étape : le tag / l’annonce 
eldy nous a confirmé que tout était ok aujourd’hui ou hier (pardon je suis un peu « charette » en ce moment et je ne vois pas les jours défiler)…
nous nous réunissons tous les jeudi avec lionel pour bosser ensemble sur ce projet, j’espère donc que ce jeudi sera « le bon » pour finaliser totalement cette naissance de la 1ere release LTS 18.0.7 !
Bravo à vous deux, c’est un super boulot que vous faites !
Désolé pour ma rapidité, la publication sur sourceforge datait de mi mai il me semble 
Je ne ferai plus @erics , promis !
@+
hahaha pas de soucis @Philazerty au contraire moi j’ai trouvé ça super plaisant de voir l’info arriver « toute seule » c’est aussi la force d’une communauté ! continue !
oui ça date un peu, mai avec ses ponts et autres jours fériés a été compliqué pour nous …
Éric
Hello,
j’ai du mal à comprendre le processus.
Généralement le tag c’est la première étape d’une release qui permet de figer le code de la version.
Cela fonctionne à l’envers pour Dolibarr ?
Je ne comprends pas non plus pourquoi les nouvelles versions sont publiées sur sourceforge alors que le code source est sur github. C’est pour respecter l’adage pourquoi faire simple quand on peut faire compliqué ?
@Beers
les process ont été créés bien avant que nous ne nous impliquions dans la LTS et comme nous procédons étape par étape il est important de ne pas débarquer dans un lieu qui fonctionne et de « faire la révolution »
À titre personnel dans d’autres projets que j’ai mené jusqu’à présent le responsable du dépôt git ajoutait un « tag spécial » lequel provoquait automatiquement la mise en paquet (par jenkins, hudson et autres agents logiciels)… c’est par exemple le cas pour smartmaker/smartcommon mais ce n’est pas le sujet de ce thread du forum.
Donc a) nous apprenons et solidifions une étape critique de publication de dolibarr qui passe - à priori - de environ 1 à 3 personnes capables de le faire en suivant une procédure déjà existante.
Quand à la procédure existante il faut considérer l’historique : github n’existait pas … SourceForge était alors le « centre » et la migration vers github a été centrée sur le code et pas les releases. Comme je ne suis pas un grand fan des forges non libres et hypercentralisées je ne peux pas en dire plus mais il me semble me souvenir que la notion de « release » est arrivé assez tardivement sur github.
Pour en revenir à pourquoi le tag n’est pas publié en premier c’est lié au process de création des releases : tiens un exemple tout con le ChangeLog. Le tag est posé avant ou après ? Certains disent que créer le tag implique la création automatique du ChangeLog … soit mais en ce cas le fichier ChangeLog est généré après le tag … donc il ne sera pas lui même dans le tag 18.0.7 ? et il y a d’autres petites bricoles liées au process de packaging, exemple si certains fichiers de déploiement doivent être modifiés (wamp ou deb ou autre) … il faut être en mesure de poser le tag après les petites « tambouilles » de release.
À moins de considérer qu’une release n’est qu’un tarball de l’arborescence git mais je crois que ça n’est pas le sens de « release » de dolibarr.
Dans le cas particulier de la 18.0.7 LTS « première » release de notre tandem de choc nous avons généré une bonne dizaine de fois les différents paquets, envoyés sur les serveurs, vérifiés, testé, rencontré plein de problèmes et avons modifiés pas mal de choses (scripts de génération des packages en particulier) … heureusement que le tag n’était pas la 1ere chose à faire sinon ça aurait fait du « rififi » sur le serveur et nous serions à la 18.0.58 au moins 
!
J’espère avoir répondu à ta question.
Dernier point je crois que sourceforge est central car il permet d’avoir les stats de téléchargement il me semble que sur ce point github est muet ?
Note: tout ce que j’écris sur le forum n’est qu’une expression personnelle et non une version officielle du projet dolibarr, je peux me tromper et faire des erreurs en particulier pour cette partie « release management » qui est vraiment particulière.
Bravo à Eric et Lionel pour ce travail ainsi qu’à toutes les personnes ayant contribué à créer cette version. En route pour la prochaine
Le process qui est quasiment identique sur tous les projets que je connais, c’est la création d’une branche temporaire release candidate, sur laquelle on applique les derniers ajustements (comme le changelog par exemple). Une fois qu’on est satisfait du résultat et que tout est prêt on ajoute le tag de la release et on merge dans la branche qui va bien et on supprime la branche temporaire.
Et le but de mes questions ce n’est pas de faire la révolution, mais d’arriver à comprendre comment est géré le projet Dolibarr.
Bonjour
Merci à toutes et tous pour ces efforts !
C’est bien le but et tes questions contribuent à ça, c’est vraiment la qu’on voit la qualité d’une communauté : proposer des améliorations c’est pas que sur le code mais aussi sur les process, le fonctionnement etc.
C’est une excellente piste à proposer pour améliorer le process ! Nous avions envisagé ça avec Lionel: publier la RC sur un dépot git « à nous » pour y pousser nos « bricolages » (en fait c’est surtout que plein de bricoles nous ont demandés beaucoup de temps et d’une semaine sur l’autre le risque de « perdre » des informations était bien réel) mais comme ça ajoute encore du boulot sur la tête du chef mergeur (eldy) au final donc nous nous sommes appuyés sur des outils plus lowtech (fichier plat, wiki, notes, mails, papiers brouillons) … mais c’est probable qu’on arrive « un jour » à ce genre de choses … laissons le temps à la machine de se roder, ça ne se fait pas d’un claquement de doigts ce genre de choses
Si ce n’est pas déjà fait, je propose d’ajouter la mise à jour de cette page du wiki dans la procédure : Liste des versions, journal des modifications et compatibilités — Dolibarr ERP CRM Wiki et pourquoi pas une étape de comm. sur le site de Dolibarr et le forum mais là on commence a être hors procédure technique.
Hello
dernier point ce matin avec Lionel, à priori nous n’avons pas le droit de pousser les tags sur le dépôt github raison pour laquelle (sauf autre erreur) le script « qui fait tout » ne l’a pas fait
Hello,
Je vais aussi adopter la LTS pour mes clients
Je suis dispo si vous avez besoin d’aide pour de la doc, des tests ou autre sur la LTS.
+
