On Sun, Oct 18, 2015 at 2:52 PM, Laurent Destailleur (aka Eldy) < [email protected]> wrote:
> I would like to clarify some things, a lot of wrong information was > related here on this post, probably due to a bug between sync between > GitHub and SF. > > * SF is the place used to store packages. It hosts only downloadable > packages. Not sources. So it provides mirrors to download installers > packages (some are large binary packages dedicated to an OS). Sources you > can see on SF are just (should just be) a real time mirror from github. > However it seems a bug between SF and github make sync failed since 13 > september 2015. This seems to creates confusion on how release are done. > To avoid confusion, i will try to restore the sync github -> SF. It it > fails (problem seems to be on SF side), I will just completely remove the > mirroring of sources. > > * Version .0 are not beta version but they are stable version dedicated to > users. Such stable version are scheduled not only by a date but also by > opened issues. So the date is just an estimated information. In most cases, > it just means "Will be release after this date, when everything is ready". > The real thing that trigger the release is: > Is there any feedback or issue that are critical still opened during or > before the beta period ? If yes, release wait features are stable and > issues are fixed. If no issue are known, if no warning are up, and date of > roadmap is past, release can be done. That's why release are sometimes > late, like it was for 3.7 version because of the critical bug in mysql > 5.5.40. > > * Release and tagging of version is already done automatically. Packages, > controls and tags of source are done by the same scripted process, so human > error should not happen. > > > Thanks for clarifying it. Rgds Saxa > 2015-10-15 16:24 GMT+02:00 Sasa Ostrouska <[email protected]>: > >> >> >> On Thu, Oct 15, 2015 at 8:11 AM, CF <[email protected]> wrote: >> >>> 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. >>> >>> SF is a good place to host downloads in my opinion, the thing is to make >> a script which would take care of those issues. >> A script should do the tarball, the upload and the git tags. In that way >> we would not have anymore differences between the git tree and the uploaded >> tarball, of course if nobody then commits to the tagged tree. The script >> should also create a new tag+1 branch where all the bug fixes should enter >> until the script is run again. In other words automatization of the process >> is needed. Human make errors. >> >> >> Rgds >> Saxa >> >> >>> >>> 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 >>> >>> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > > > -- > EMail: [email protected] > Web: http://www.destailleur.fr > > ------------------------------------------------------------------------------------ > Google+: https://plus.google.com/+LaurentDestailleur/ > Facebook: https://www.facebook.com/Destailleur.Laurent > Twitter: http://www.twitter.com/eldy10 > > ------------------------------------------------------------------------------------ > * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for > Dolibarr project via Paypal: [email protected]) > * AWStats (Author) : http://awstats.sourceforge.net (make a donation for > AWStats project via Paypal: [email protected]) > * AWBot (Author) : http://awbot.sourceforge.net > * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net > > > > _______________________________________________ > 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
