Raphael thank you for this synthesis
There actually is a problem of manpower for testing and probably more time will not change. It prevents many of us to look after our customers and finaly run out of time to work on the core. This is due that we stay between developers, or Dolibarr users must be more implicated on the development phases and particulary the test. The establishment on an "visible" RC version (in the .fr and .org website) will permit users (not necessarily developer) to test more in depth version of this qualification and return faults detected. This is probably also to us to "educate" our clients to back the bugs. everyone will win. Maybe create a job of relationship (R2D2 ;-P ) between developers and users is a good way 3.7 is on the way, do not bother to stop, but take the time to ask the right questions for the next release, - LTS or not - asking the users of priority new feature - Test period with user more implicated - … Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Doursenaud, Raphaël Envoyé : lundi 3 novembre 2014 18:32 À : Posts about Dolibarr ERP & CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Hi everyone, Sorry I'm a little late to the party, i was taking vacations :D Dolibarr release cycle is … well … a release cycle. There is no right or wrong way, only infinite possibilities in between. What we should account for first, IMHO, is the size of the manpower we have driving the main development. Looking at the numbers (git shortlog -sne 3.6.0..develop) , we're not that much. I get 71 different committers (based on email addresses so a few dups). eldy being the main man (More than 50% of the commits kudos to him!) and second man being at a mere 8% (!). The core team is composed of 15 people at most. Numbers are pretty much the same for the previous cycle. But for maintenance release (git shortlog -sne 3.6.0..3.6), only 20 committers with again eldy almost hitting 50%. This means two things: - First, developers seem to have no interest in maintaining the code. So having longer integration periods will, as said eldy, only make things worse. - Second, we don't have much resources so we must keep things as streamlined as possible and use them wisely. I have a feeling that maintaining 3 versions (n, n-1 & n-2) is already a _huge_ effort. Of course, we could use a LTS scheme but someone need to step up to spec and lead the project. Although I very much like the idea, I'm not volunteering, I'm already unable to make a friggin' release (yeah, shame on me, but I spec'd it already). I also like the "Release often, release early" mantra often used in free software communities so we should keep going. Shifting the release dates may have some advantages for commercial users, I kind of like the idea but you can't make everybody happy. Some things stroke me though: - Updating looks like a pain for our users. Maybe it's time for some "Automatic" (read Assisted) upgrade mechanism. Could make a nice bounty, I'd certainly pay for that. - Some bugs stay unfixed between versions. Maybe we should try putting up some events like "bug squashing day" or whatever, once a month with some nice rewards (Thanks email, a wiki and/or forum badge, a hug. Yeah, resources are pretty scarce these days but you get the idea) as an incentive to get developers and users interested in maintenance. (I'm guilty not being.) - Updating breaks external modules. Well that's very unfortunate they're external… (Sorry, couldn't resist) We can't guarantee a stable API without some heavy burden on our Yodas and I don't think they'd like it. Also, if you're a module developer, it's your responsibility to make the modifications needed in the integration period ! You're doing two things at once doing it there. Make sure your module works with the new Dolibarr and that Dolibarr is bug free on release. Does it sound nice or what. Also, unlike proprietary software, the code is available early so you really have no excuses. Incompatible changes are often very well documented in the ChangeLog. But feel free to contribute some core code that'll make your life easier (Better API, looser coupling, your module…). Anyway, my 2 cents, 2014-11-01 22:42 GMT+01:00 <charles...@benke.fr>: If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing Maybe 6month it's a good frequency for the developer, but it's not for the users and our customers who don't want to upgrade his ERP every 6 month for only 50 new features each (ok 3.7 version have a little more) Another bad point is the timing of the January major release : many users are in installation and start using Dolibarr who have just installed at the end of year My position is to change the planning and add a release candidate (RC) between the beta and the stable version. RC version is an official test version for customer We diffuse it on Dolibarr website download area between the stable and pre-release (Besides the alpha and beta version posted on the download area is 3.6 not 3.7) RC version will permit of dolibarr user (not only developer user to made more test) propose the following roadmap mai YYYY - Beta Release (version A.B.0 beta) (freeze) june YYYY - Release Candidate (version A.B.0 RC) August YYYY - Major Release (version A.B.0) September YYYY - Major Release (version A.B.1) october YYYY - Alpha Release (version A.B+1.0 alpha) with 8 month for development and 4 month for test Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -----Message d'origine----- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr <mailto:dolibarr-dev-bounces%2Bcharles.fr> =benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : samedi 1 novembre 2014 21:14 À : Posts about Dolibarr ERP & CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Having more time to test will not change anything. If you have more time, you will have also more regression and motre things to test. In fact, if time between 2 release is increased by 2, the time neeed to test and upgrade a module is increased by 4 and time required for beta is also increased by 4 instead of 2 making finally less time to have a stable version to make quality tests. That's why more and more projects are making rolling released (so a released every month and even weeks). But I think 6 month is a good frequency to not have to wait to long to get new features. Also a roadmap must be followed as announced other wise it has no senses to have roadmap. 2014-10-27 0:55 GMT+01:00 <charles...@benke.fr>: > Freeze the develop branch to start beta in not a good idea : we need > more time between 2 major versions (One year, not six month) to test > and develop ours modules. > > If we maintain this crazy rate of two major releases per year, I will > no more upgrade my modules for the February version. > > It's time to make quality more than quantity > > Bien cordialement, > Charles-François BENKE > http://www.benke.fr - 0637056117 > > -----Message d'origine----- > De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org > [mailto:dolibarr-dev-bounces+charles.fr > <mailto:dolibarr-dev-bounces%2Bcharles.fr> =benke...@nongnu.org] De la > part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À > : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze > > > Just a warning to remind everybody that we are reaching end of october: > This means the freeze of develop branch to start beta 3.7 will be done in > less than 7 days. > > > > -- > Laurent Destailleur (alias Eldy) > ---------------------------------------------------------------------------- > -------- > Social networks of my OpenSource projects: > Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ > Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: > http://www.twitter.com/dolibarr AWStats Google+: > https://plus.google.com/+AWStatsOrgPoject/ > AWStats Facebook: https://www.facebook.com/awstats.org > AWStats Twitter: http://www.twitter.com/awstats_project > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > -- Laurent Destailleur (alias Eldy) ------------------------------------------------------------------------------------ Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org 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 - +33 (0)6 68 48 20 10 <http://gpcsolutions.fr> Image supprimée par l'expéditeur. 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> Image supprimée par l'expéditeur.Image supprimée par l'expéditeur.
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
