D’autres logiciels utilisent un double système, il annonceraient les « pre-release 19.0.x » pendant quelques semaines, puis au bout de quelques semaines, ils annonceraient la release finale qui serait un 19.0.4.
C’est pour inciter certains à tester et qu’ils sachent qu’en cas de bug, ils peuvent le remonter et que les pre-releases se succèdent rapidement.
J’ai cru comprendre qu’il y aurait peut-être prochainement un gel exceptionnel de l’arrivée de nouvelles fonctionnalités dans Dolibarr pour forcer les gens à mettre des efforts sur la correction des bugs. 2 ou 3 releases par an, c’est beaucoup ou alors il faudrait ne garder le premier chiffre de version uniquement quand il y a un changement dans la base de données et le faire qu’une fois par an, et avoir des sous-versions sur l’année.
Je le fais un peu de mon « propre chef », avant c’était @eldy ou @aspangaro-Easya qui s’occupait de ça principalement.
Si vous avez des suggestions sur ce qui est mis en avant ou pas, je suis prenneur !
La difficulté est que l’on veut qu’un maximum d’utilisateurs adoptent une version x.0.0 pour justement avoir des retours qui permettent de la stabiliser. Si on ne communique plus sur ces nouvelles versions, c’est le risque.
Mais pour info, par rapport à la V19, j’ai volontairement laissé la V18.0.5 sur les banniéres des forums EN et FR, car il me semble plus important le correctif de la faille de sécurité, considérant que les utilisateurs actuels de Dolibarr sont plutot sur le forum que sur la page d’accueil du site dolibarr.org.
Même logique pour Doliwamp que je n’ai pas packagé en V19 (en dehors du faite que je n’arrive pas à le passer en php V8…)
Par contre, pour quand même donner un peu de visibilité à cette V19, le message a été mis sur le dolibarr.org, qui est plutot à destination des nouveaux utilisateurs.
Bref, il n’y a pas de régles à ma connaissance, mais ensemble on pourrait les écrires ,au moins sur la partie communication (sans rentrer dans le débat sur le bien fondé des 2 versions majeurs par an).
Si je résume ce qui a été dit plus haut ça serrait de présenter sur le dolibarr.org la nouvelle version x.0.0 comme étant une pré-release ? et ensuite, quand on est en V x.0.1 ou 2 comme une release (pas finale car il n’y en a jamais vraiment) ?
Peut-être est-ce possible d’afficher deux versions en parallèle en choisissant des termes adjectifs pour donner une couleur aux versions, exemple :
18.0.4 (version éprouvée), 19.0.0 (version récente)
Dans quelques mois, on verrait par exemple :
19.0.3 (version éprouvée), 20.0.0 (version récente)
Donc si je traduis : on met en avant la version x.0.0 pour que des utilisateurs plantent leur prod et remontent des anomalies… c’est le risque
Pour le moment on a pas eu de gros plantage avec perte de données, mais je jour ou cela arrivera on diras quoi ? « c’est le risque »?
Faire une fresh install et jouer un peu avec une nouvelle version serait aussi un minimum, j’ai l’impression des fois que l’on se repose tellement sur les tests unitaires que l’on laisse passer des plantages monstrueux.
Généralement, les personnes qui connaissent dolibarr, savent ou aller récupérer une double-zéro, l’annonce sur le forum suffit (ou le github).
il me semble que d’annoncer seulement à partir d’une 0.1 serait plus pertinent.
Des fois d’avoir un peu d’humilité, en particulier sur la diffusion d’un version que l’on pense stable ne serait pas du luxe (surtout en période de carême …)
Pour ma part je rejoins @eldy. Si on annonce d’attendre la version x.0.1 pour mettre en prod, bientôt il faudra annoncer d’attendre la x.0.2, etc.
La phase beta dure environ 2 mois et est là pour s’assurer de la stabilité du logiciel, si en annonçant la release on dit en même temps d’attendre, on se tire une balle dans le pied. De plus, dans la majorité des cas, les utilisateurs qui ont déjà Dolibarr ne vont pas sauter sur la nouvelle version dès sa sortie si elle ne leur apporte rien de + que celle qu’ils ont. On ne fait pas une montée de version de l’ERP de l’entreprise sans objectifs et sans planification.
Le vrai sujet est d’avoir + de testeurs notamment pendant la phase beta. Il y a plein de contributeurs pour ajouter des fonctionnalités à Dolibarr mais trop peu pour corriger les bugs où même améliorer l’existant en se basant sur les nouveaux standards. Et c’est aussi pour ça qu’on avance sur des outils de vérification de code, de tests automatisés, qu’on en remet une couche pendant les devcamps avec des bugfix contests aussi, etc.
Sauf que considérer la v .0.0 comme étant une version de qualification avec beaucoup de testeur qui ne testeront pas une béta qui évoluent toute les semaines pour ne pas dire tout jours…
Une fois de plus, c’est beau la théorie, mais diffuser une version qui n’a pas suffisament été testé, c’est clairement mettre une balle dans le pied à des utilisateurs n’ayant pas de qualifications…
Limite c’est à se demander si ce n’est pas pour qu’ils plantent leur prod et ensuite les obliger à prendre de la presta et du cloud …
Enfin bref, il faut etre cohérent, soit on dit que l’on manque de testeur et on ne balance pas une version pas assez testé, soit on diffuse une version de qualification pour des insiders à ne pas mettre en prod…
Le vrai sujet c’est d’avoir des versions bêta, ensuite on pourra avoir des testeurs pour des versions bêta.
Il n’existe pas à ce jour de version bêta dans les releases Tags · Dolibarr/dolibarr · GitHub.
Un projet avec des versions bêta cela ressemble à ça au niveau des releases:
Sortir une v x.0 stable dès le premier jour, c’est impossible sans une base minimum de beta testeur et sur une durée longue.
EspoCRM qui est très bien codé, prend un peu plus d’un mois pour être stable.
Debian annonce toujours d’avance une révision x.1 4 semaines après chaque release majeure.
Joplin utilise des pre-release
Nextcloud n’a rien et c’est une catastrophe, pas stable, mal codé,…
Il n’y a donc aucun moyen d’échapper à une période de test après l’annonce d’une sortie. Il faut simplement jouer sur les mots utilisés et sur le fait qu’il y aura toujours des personnes à utiliser une x.0 si on leur dit que la version est sortie, même si on dit que la version x.1 est planifiée 4 semaines plus tard. Les habitués qui veulent une prod stable attendront toujours la x.1.
C’est juste une question d’enrobage.
Il suffit juste de dire/écrire/planifier un x.1 sans dire rien d’autres. Et s’il y a une LTS, il faudrait afficher la LTS en parallèle.
Je rejoins hop, une beta ce n’est pas juste un tag dans github, beaucoup d’utilisateur de dolibarr ne savent pas utiliser git…
A un moment ce serait bien de comprendre que la majorité des utilisateurs de dolibarr :
ne codent pas,
n’ont pas de compte github
ne lisent pas les post sur ce forum,
et ne comprennent meme pas les termes de béta, qualif, lts…
Bonjour à tous,
Je ne sais pas si je peux intervenir dans ce fil, surtout après le post de defrance
Je suis utilisateur (ancien) de Dolibarr.
Je lis les posts du forum (la preuve).
Je code un peu depuis quelques années.
Je n’ai pas de compte git… (defrance a raison !)
Il y a quelques années j’étais aussi intervenu sur un fil qui concernait la remontée d’utilisateurs/testeurs.
A l’époque je soulignais l’absence de procédure simple et efficace pour un testeur lambda pour signaler des « bugs ». Je le mets volontairement entre guillemets car ce ne sont pas toujours des bugs effectifs (problèmes de paramétrages, d’os, php…).
Aujourd’hui je ne sais toujours pas comment remonter efficacement ce que je trouve dans les versions que je teste…
Actuellement je commence à tester la v19 (je suis en production sur une 17.0.3) pour une bascule cet été ou fin d’année (donc avec une version 3, 4 ou 5 !), mais je fais ça dans mon coin avec mon petit tableau excel et je surveille ce qui sort comme patch et si pas de patch et bien je fais tout seul…
Et je fais cela tous les ans ou tous les 2 ans depuis la version 3.5.3 !
Effectivement le jour ou je pourrais simplement remonter ce que je trouve et en faire profiter la communauté, je le ferai avec grand plaisir !
Francis
Comme le projet Dolibarr ne travaille que sur une seule version beta à la fois, il n’y a pas lieu d’avoir des tags pour en suivre plusieurs en même temps. git permettant déjà de tout suivre ou récupérer sans cela (en effet, 24 après le lancement d’une beta, le tag est déjà obsolète alors que la branche elle est toujours à jour) .
Il y a une version beta touts les 6 mois, à chaque nouvelle version stable qui se profile. Cette version est annoncée sur le site web (rubrique actualité, flux rss et réseaux sociaux) 2 à 3 mois avant la sortie officielle.
Le lien pour récupérer les sources est également fourni dans le message. C’est en général la branche develop qui sert de référentiel de travail de la beta, puis la branch X.Y du nom de la future version (aucune nouvelle fonctionnalité n’est intégrée alors dans cette branche durant les 2 à 3 mois de la beta).
Les versions beta sont donc récupérés par les beta testeurs via git clone et non plus par téléchargement de zip, ce qui permet de mettre à jour sa beta avec les corrections de la journée en une simple commande. Il y a environ une trentaine de personnes qui interviennent durant la phase beta, ce qui semble beaucoup mais ne l’est pas tant que ça sur une projet de la taille de Dolibarr, d’autant que ce n’est jamais un investissement des debuggueur à temps plein.
Une fois que les 2 conditions « Date prévu de release atteinte » + « Plus aucun bug critique connu non corrigé » sont atteintes, la release sort, ce qui explique que la date de release est légèrement variable par rapport à la date prévue (dans les faits les bugs bloquant pour release sont en général tous corrigé entre 0 et 45 jours après la date officielle, ce qui explique que la version stable sort (tag posé sur github) entre 0 et 45 jours après la date prévue.
L’annonce officielle étant faite par différents bénévoles sur différents canaux, il y a en général encore un décalage de quelques jours avec la diffusion des annonces.
Le choix de passer en production ou non dès l’annonce relève de choix personnel ou d’exploitation.
PS: J’en profite pour remercier ses acteurs bénévoles de la communauté qui aident le projet sur d’autres aspect que le développement en assurant la communication des sorties Dolibarr, et les encourage à faire abstraction de injures de certaines personnes qui cherchent à les dénigrer sur ce forum en considérant leur travail « calamiteux », car il n’en est rien. Bravo et continuez, on a besoin de vous…
Le site web www.dolibarr.fr propose un lien « Gestionnaire de bug » (dans la section « Communauté ») qui renvoi vers l’outil centralisé de déclaration de bug de Dolibarr. La déclaration d’un bug nécessite en effet de créer un compte (comme pour l’outil forum). Si cela peut être vu comme une contrainte de créer un compte github, il faut savoir que ceci est nécessaire car permet de contrôler les messages postés et réduit de manière très importante le taux de fausses déclarations (messages spam parasites) par rapport à un système en déclaration sans compte. Une déclaration de bug nécessite aussi souvent des échanges avec la personne qui a soumis le bug et pour cela une identification de la personne avec son email est nécessaire (même si l’email n’apparait pas en clair).
Pour ces 2 raisons, il n’est pas prévu de basculer sur un système de déclaration de ticket qui éviterait l’étape de création d’un compte.
Si cela peut donner des pistes, le projet LibreOffice utilise la notion de version « Evolution » et « Stable », extrait de leur page de téléchargement :
« Évolution » est plutôt destinée aux utilisateurs avancés impatients de tester les nouveautés de LibreOffice. Les autres choisiront la version « Stable ». Cependant à partir de la 4e mise à jour corrective (version x.y.4 par exemple) la branche Évolution est prête pour une utilisation en entreprise et des déploiements à grande échelle.
Participant à la chasse aux bugs et la qualité du code, mon impression aujourd’hui serait que la v19.0.0 équivaut une version « Evolution » et la v18.0.5 la version dite « Stable ». Sans parler des problématiques de beta-testeurs et de FDKs, peut être qu’il y a un léger ajustement à faire sur les noms des releases pour donner plus clairement une indication dans ce sens. Attention, les termes employés ne doivent pas déséquilibrer les téléchargements/installations. Faudrait pas freiner ceux qui souhaitent installer la dernière version ou à l’inverse qu’il n’y ait plus de remontées sur les versions précédentes.
Le problème c’est que ce système exclu de fait toute personne qui n’est pas développeuse ou développeur. On ne peut pas se plaindre d’un côté de manquer de testeurs pour les version bêta et limiter l’accès aux versions bêta aux seules personnes familières avec l’usage de github.
On se prive de la quasi totalité des utilisateurs au quotidien de Dolibarr, qui eux deviennent bêta testeurs « forcés » lorsqu’ils installent une version x.0.0
Bonjour, parfaitement d’accord avec @hop sur ce point; je rajouterai également l’obstacle de la langue anglaise pour les utilisateurs lambda francophones.
