Well, release tagging is a very simple and straightforward operation that our project maintainer gets wrong every time for god knows what reason… I think it's because there is no "Gold master release" other variants are built upon and the lack of a formal release procedure. Having release variants is normal. For example, the debian package have a specific set of requirements and some files are purposely removed. But files present should match the release tag in repository. I drafted a release procedure some years ago when I was appointed release manager: http://wiki.dolibarr.org/index.php/ReleaseProcess But I never got around implementing it because I don't understand how releases are done right now and I wanted to avoid regressions. Maybe I'll give it another shot one of those coming long winter nights. Try keeping me motivated ;)
2015-10-15 10:11 GMT+02:00 CF <[email protected]>: > 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]>: > >> 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] >> 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 > [email protected]https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > _______________________________________________ > Dolibarr-dev mailing list > [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
