On Wed, Nov 5, 2014 at 7:48 AM, Doursenaud, Raphaël < rdoursen...@gpcsolutions.fr> wrote:
> > 2014-11-05 10:56 GMT+01:00 Christophe Battarel < > christophe.batta...@altairis.fr>: > >> Not sure it will work but we can try... i dont know many end users who >> tests beta versions; usually they wait for the "stable" release and they >> report bugs at this time (look at the posts in french forums when 3.6 was >> out...) >> For what i understand from your RC stuff, if we take an example with >> 3.5.x releases, 3.5.0 should have been the first RC and 3.5.5 the stable >> release ? >> > > No, not at all. We would have a RC cycle between the beta phase and the > definitive release. > The cycle would go that way : > Beta(last)-> RC(1) -> RC(n) -> RC(last) == Release(x.y.0) > > - Beta(last) > After some betas, we consider the thing is stable enough and will not have > any catastrophic behavior so we're confident users can go and test it > without any major harm. > - RC cycle > We try to promote the RCs as much as possible so we have enough people > testing with their actual workflow and data (This is the only way to iron > out all the bugs). > - RC(last) > Once the reported _and_ fixed bugs is low enough or even better, zero. We > know this is good for release so **we don't touch it**, just rename it to > release x.y.0 > > The hotfix releases (x.y.n) will continue to come out when problems are > found in the field after release. > > This is not rocket science and pretty much the proven standard in the > industry. If you want to learn more: > https://en.wikipedia.org/wiki/Software_release_life_cycle > > Cheers, > hi, my thoughts on this are that this is really how most of the OSS work, but at the end is just a matter of naming. I think that the real problem lies in the development forces and the coordination between them. This means that if everybody could be able to pick up an open bug and work on it, it would really speed up the things. Right now as you stated most of the bugs are fixed at the end by one developer. Immagine a way of how to assign bugs to various developers, would not that work much faster ? At the end the release is just a point in time of some code movement, therefore, nameing it 1 or x or RC doesnt really matter much, In my opinion the micro releases should be done in a faster way, rolling them out at each few bugs fixed, for example 5 or 10 bugs or even less. The major releases then would have more time to get baked well. Also remeber ERP software is something different from a drawing like software, you deal with peoples company data, or better yet, peoples money. In my company for example I preffer to use as much time the thing which works and tend not to upgrade the thing too fast or every release for example. Some other people would wait for some features and maybe have the necessity to update faster, but this is something you will never be able to make happy everybody. Important thing is that the upgrade goes as much as possible flawlessly. So to resume, my opinion is that having a major release 1 per year and done really well. And in the middle time a lot of micro releases. Of course the most important way is to make a TODO list and follow it. My 2c, Rgds Saxa PS: Raphael, I dont know why your e-mails always end in my spam box on gmail. Any idea ? > -- > *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
