Integrator and advanced users are likely to be recruited for his last intermediate tests. Since I had the painful case with 3.7 a crash on extrafields following a last-minute change between the beta and the final, I wait to test my modules the official version.
Another possibility would be to not automate online on sourceforge but to wait 2 or 3 weeks between the unofficial release on github and the official release on sourceforge. During this period functional testers could do some additional tests (see some patches). before the official release. intégrateur et utilisateurs avancés sont sans doute à recruter pour ses derniers tests intermédiaire. Depuis que j'ai eu le cas douloureux avec la 3.7 d'un plantage sur les Extrafields suite à une modification de derniere minutes entre la béta et la finale, j'attends pour tester mes modules la version officielle Une autre possibilité serait de ne plus automatiser la mise en ligne sur sourceforge mais d'attendre 2 ou 3 semaines entre la sortie officieuse sur github et la sortie officielle sur sourceforge. Durant cette période des testeurs fonctionnels pourraient faire quelques tests supplémentaires (voir quelques correctifs). avant la sortie officielle. De : [email protected] [mailto:[email protected]] De la part de Maxime Kohlhaas Envoyé : lundi 19 octobre 2015 09:05 À : Posts about Dolibarr ERP & CRM development and coding <[email protected]> Objet : Re: [Dolibarr-dev] Dolibarr 3.8.1 and freeze of Dolibarr 3.9 As I understand, from the customer side, .0 versions are not stable enough, and from the developer side, .0 versions are released when there are no more issues or feedback. So the real problem is between the two sides, there are not enough beta testers. Perhaps more communication when a beta version is released, or a direct communication to recruit beta testers... Bien cordialement, -- <http://www.atm-consulting.fr/> Maxime Kohlhaas I Consultant Associé 26 rue Barthélémy de Laffemas - 26000 Valence <mailto:[email protected]> [email protected] Tél : 06 33 42 92 43 <http://www.atm-consulting.fr/> www.atm-consulting.fr <https://www.facebook.com/atmconsulting26> <https://twitter.com/atm_consulting> <https://fr.linkedin.com/company/atm-consulting-valence> <https://www.youtube.com/channel/UCYAZ-SPhzg9R87uppAvem0Q> 2015-10-18 20:32 GMT+02:00 Sasa Ostrouska <[email protected] <mailto:[email protected]> >: On Sun, Oct 18, 2015 at 2:52 PM, Laurent Destailleur (aka Eldy) <[email protected] <mailto:[email protected]> > wrote: I would like to clarify some things, a lot of wrong information was related here on this post, probably due to a bug between sync between GitHub and SF. * SF is the place used to store packages. It hosts only downloadable packages. Not sources. So it provides mirrors to download installers packages (some are large binary packages dedicated to an OS). Sources you can see on SF are just (should just be) a real time mirror from github. However it seems a bug between SF and github make sync failed since 13 september 2015. This seems to creates confusion on how release are done. To avoid confusion, i will try to restore the sync github -> SF. It it fails (problem seems to be on SF side), I will just completely remove the mirroring of sources. * Version .0 are not beta version but they are stable version dedicated to users. Such stable version are scheduled not only by a date but also by opened issues. So the date is just an estimated information. In most cases, it just means "Will be release after this date, when everything is ready". The real thing that trigger the release is: Is there any feedback or issue that are critical still opened during or before the beta period ? If yes, release wait features are stable and issues are fixed. If no issue are known, if no warning are up, and date of roadmap is past, release can be done. That's why release are sometimes late, like it was for 3.7 version because of the critical bug in mysql 5.5.40. * Release and tagging of version is already done automatically. Packages, controls and tags of source are done by the same scripted process, so human error should not happen. Thanks for clarifying it. Rgds Saxa 2015-10-15 16:24 GMT+02:00 Sasa Ostrouska <[email protected] <mailto:[email protected]> >: On Thu, Oct 15, 2015 at 8:11 AM, CF <[email protected] <mailto:[email protected]> > wrote: ahahah, i agre with most of your parts. Anyhow, the SF <--> Github differences should be adressed to avoid bad version number (understand: differents). I also understand SF audience is not negligeable so simply closing it seems an harsh option at this time. SF is a good place to host downloads in my opinion, the thing is to make a script which would take care of those issues. A script should do the tarball, the upload and the git tags. In that way we would not have anymore differences between the git tree and the uploaded tarball, of course if nobody then commits to the tagged tree. The script should also create a new tag+1 branch where all the bug fixes should enter until the script is run again. In other words automatization of the process is needed. Human make errors. Rgds Saxa Le 14/10/2015 18:13, Doursenaud, Raphaël a écrit : Ok, who's up for a software lifecycle and version numbering schemes thesis? Maybe you can get a PhD out of it! Jokes aside, the thing is that NO software release cycle is perfect because various audiences seek different things. FLOSS developers tend to prefer "release often, release early" and "semantic versioning". Perfectionists are going for "when it's ready" and "I only need to increase one number since every release is just perfect". Traditional corporate vendors usually prefer "Rush it out the door, we need it for yesterday, just try to hide defects under the carpet and colorful design" and "We don't care, give us the biggest number so marketing can show off". Integrators and users want "Something with all the bells and whistles that works out of the box, forever" and "No new releases, they are a pain to deploy, so give me all the features in this one". To which I reply: "Not gonna happen!". The current process is designed around the need to get code out at a regular pace with some predictability to it. It gives a version (N-2) supported roughly 1 and a half year. I don't think it's that great, but at least it's there! IMO The Dolibarr project's lifecyle is missing some key elements to achieve better releases quality before even thinking about changing the release periodicity or version numbering. Here's a non exhaustive list from the top of my head: * Standardized and enforced good commits content and messages. * Formal code reviews for everyone including the project maintainers. * Continuous integration used properly. Ie. no one can bypass it. Ever. * The previous two boils down to: no one pushes directly to the main repository. * Proper stabilization branches. One example of this is git flow but other strategies are out there. * Proper tagging. Having releases in the wild that do not match the repository tags is a waste of everyone's time. * Proper pre-release test cycle. With multiple alpha, beta and RC releases. All properly advertised to get people involved. * Testing procedures and tooling. * Automated building for all pre-releases. * Formal testing both automated (Think unit tests, selenium, test instances, fuzzing…) and manual. * Final release should be exactly the same as the last RC. * Long term commitment to lean toward modern coding practices (refactoring, objectification, automate everything…) * Bugs bissecting to fix them at the root, not only in the reported versions. * Encourage unit tests for critical bug fixes to prevent regressions. * Community driven design before coding. * … As you can see, there's a lot of work and it can't be done by any single individual. The whole community needs to get involved. But for that to happen, there should be a strong commitment from the maintainers and core developers to stick to it and make it happen. We've already made some good progresses since switching to GitHub. Code is reviewed more often and bug reports are all assessed and properly tagged (I devote some of my own time to that weekly). Keep in mind that all of that is a community effort, so the best thing to do is step up to the plate, pick a task and do something ;) Looking forward to your contributions! 2015-10-14 8:23 GMT+02:00 Jean-François Ferry <[email protected] <mailto:[email protected]> >: Hi all, Le 13/10/2015 18:38, Charles Benke a écrit : This is not the right question to ask, The right question is "how to ensure that when there is the most download of dolibarr (September to March) the broadcast version (.2 like) is as stable as possible for novice users" To answer this question we must look at the proposed roadmap with : - .0 in april, - .1 in june-july - .2 in september We are doing wrong since a long time... Versions shouldn't be related to any date but to software structure. Please see http://semver.org/ :) _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev -- Raphaël Doursenaud Directeur technique (CTO) Expert certifié en déploiement Google Apps <https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> +33 (0)5 35 53 97 13 <tel:%2B33%20%280%295%2035%2053%2097%2013> - +33 (0)6 68 48 20 10 <http://gpcsolutions.fr> http://gpcsolutions.fr Technopole Hélioparc 2 avenue du Président Pierre Angot 64053 PAU CEDEX 9 SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921 <http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions> <https://gpcsolutions.fr/wp-content/images/gfwp.png> _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev -- EMail: [email protected] <mailto:[email protected]> Web: http://www.destailleur.fr ------------------------------------------------------------------------------------ Google+: <https://plus.google.com/+LaurentDestailleur/> https://plus.google.com/+LaurentDestailleur/ Facebook: <https://www.facebook.com/Destailleur.Laurent> https://www.facebook.com/Destailleur.Laurent Twitter: <http://www.twitter.com/eldy10> http://www.twitter.com/eldy10 ------------------------------------------------------------------------------------ * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [email protected] <mailto:[email protected]> ) * AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [email protected] <mailto:[email protected]> ) * AWBot (Author) : http://awbot.sourceforge.net * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev _______________________________________________ Dolibarr-dev mailing list [email protected] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
