Etant le principal responsable des dégâts collatéraux du passage en UTF8, je prend ta remarque avec considération et fais mon mea culpa.
Pour l'explication presque la totalité du code a du être revu pour le passage en UTF-8, ce qui a représenté un travail énorme. Le délai a été si long, que le délai de beta a été réduit afin de sortir la version a temps pour la fin d'année 2008 (afin de permettre de commencer les exercices sur la nouvelle version. Il y a en effet eu pour certains utilisateurs une problème de gestion des accents sur les PDF générés. Ceci ne concernait qu'une partie des utilisateurs, ce qui explique qu'il na pas été vu car cela dépendait d'une combinaison du pagecode de la base, du serveur mais aussi du certains paramètres comme "y a-t-il des modes de paiement ajoutés en manuel". L'origine de l'install (première ou migration) jouait aussi sur l'apparition ou non du problème, ce qui explique que très peu d'utilisateurs l'ont eu et qu'il n'a pas été vu dans les phases beta. Une fois la release faite, le problème a très vite été identifié mais hélas, le projet a atteint un tel dynamisme (on va pas s'en plaindre) que le nombre d'évolution entre temps était déjà trop important pour pouvoir relivrer avec le correctifs seul. Du coup il a fallu attendre la 2.6, ce qui explique la gène (justifié) pour ceux qui se sont trouvés dans cette situation.
Pour que ce genre d'incident ne se produise plus, le processus de release a été revu à partir de la 2.6. Dorénavant, la procédure de packaging intègre la création d'une branche CVS. Ceci permet, si le besoin se manifeste, de fournir des patch aux cas bloquants (2.6.1) par exemple et donc rapidement car indépendant de la branche de développement qui prépare déjà la 2.7.
Cette précaution qui devrait être systématique doit répondre à tes interrogations.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: gestion des bugs sur dolibarr
Posté par Laurent Destailleur (site web personnel) . En réponse à la dépêche Sortie de Dolibarr 2.6. Évalué à 4.
Pour l'explication presque la totalité du code a du être revu pour le passage en UTF-8, ce qui a représenté un travail énorme. Le délai a été si long, que le délai de beta a été réduit afin de sortir la version a temps pour la fin d'année 2008 (afin de permettre de commencer les exercices sur la nouvelle version. Il y a en effet eu pour certains utilisateurs une problème de gestion des accents sur les PDF générés. Ceci ne concernait qu'une partie des utilisateurs, ce qui explique qu'il na pas été vu car cela dépendait d'une combinaison du pagecode de la base, du serveur mais aussi du certains paramètres comme "y a-t-il des modes de paiement ajoutés en manuel". L'origine de l'install (première ou migration) jouait aussi sur l'apparition ou non du problème, ce qui explique que très peu d'utilisateurs l'ont eu et qu'il n'a pas été vu dans les phases beta. Une fois la release faite, le problème a très vite été identifié mais hélas, le projet a atteint un tel dynamisme (on va pas s'en plaindre) que le nombre d'évolution entre temps était déjà trop important pour pouvoir relivrer avec le correctifs seul. Du coup il a fallu attendre la 2.6, ce qui explique la gène (justifié) pour ceux qui se sont trouvés dans cette situation.
Pour que ce genre d'incident ne se produise plus, le processus de release a été revu à partir de la 2.6. Dorénavant, la procédure de packaging intègre la création d'une branche CVS. Ceci permet, si le besoin se manifeste, de fournir des patch aux cas bloquants (2.6.1) par exemple et donc rapidement car indépendant de la branche de développement qui prépare déjà la 2.7.
Cette précaution qui devrait être systématique doit répondre à tes interrogations.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)