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.
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 - +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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
