On Mon, Nov 3, 2014 at 2:32 PM, Doursenaud, Raphaël < rdoursen...@gpcsolutions.fr> wrote:
> 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, > > Good observations Raphael. Rgds Saxa > > > 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=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=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> > 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> > > _______________________________________________ > 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
