Until now the creation of a release branch every year made sense and the 09.04, 10.04, 11.04, 12.04 and 13.07 look very different ones from each other. Sometime during the Spring-Summer of 2014 we could compare the trunk with the 13.07 release branch and decide what to do; if they don't look very different we could check again in 6-12 months or so. In short, I agree with the idea that a release branch should be created only if it is significantly different from the previous one (and this has been always true till now); however I think that a yearly check to see if a release branch should be created is a good thing, if it doesn't imply that we have to create a branch each year.
Regards, Jacopo On Aug 9, 2013, at 4:14 PM, Jacques Le Roux <[email protected]> wrote: > It seems we are all almost on the same page. I will wait a bit more for other > opinions, vacations time... > > Jacques > > ----- Original Message ----- > From: "Adrian Crum" <[email protected]> > To: <[email protected]> > Sent: Wednesday, August 07, 2013 4:31 PM > Subject: Re: [PROPOSAL] New way for releases scheduling > > >> Thanks Scott. I agree with you. >> >> -Adrian >> >> On 8/6/2013 6:53 PM, Scott Gray wrote: >>> My opinion is that we should release whenever we (the community) feel the >>> features added since the last release warrant it. There's no point in >>> making releases if they add little value on the previous and there's no >>> point in waiting some arbitrary amount of time before releasing good >>> features. >>> >>> User's aren't obligated to upgrade every year just because we release >>> something. It only ever makes sense if the release holds more value to >>> them than the cost of upgrading. So at a minimum an upgrade would only be >>> needed every 3 years (and only if the user didn't have the resources to >>> manually backport security/stability fixes) based on the current release >>> schedule. >>> >>> In general though I agree we could increase our maximum wait between major >>> releases to something more than a year. >>> >>> Regards >>> Scott >>> >>> On 7/08/2013, at 1:02 AM, Jacques Le Roux wrote: >>> >>>> Hi, >>>> >>>> For some days now, I was thinking about a "new way of releasing" (only >>>> schedule related). I thought about it while looking by chance at release >>>> strategies of few other Apache projects. Notably how they plan things... >>>> >>>> Today, a reminder poped up for the "End of month: Main New Features" mail >>>> I send every end of month. I believe there were not much, if any, main new >>>> features last month, but it reminded me about the ideas I had on releases >>>> scheduling. >>>> >>>> My proposition is to not release each year but every 2 or, preferred, 3 >>>> years. Here are the reasons: >>>> >>>> 1) There are less and less new features, so there are less needs to >>>> distribute often (ie every year) >>>> 2) Security and bug fixes can still be done with new minor releases >>>> 3) Users can still grab new features they want from trunk as long as they >>>> are well documented in main new feature page (maybe we should add there >>>> the revs #) >>>> >>>> >>>> PROS: >>>> * This has the obvious advantage of removing some release burden (mostly >>>> done by Jacopo these days, thanks to him) >>>> * But not only, it's also easier for users. Because moving from one >>>> release to the other each year is not very easy for a project. For some >>>> project it takes sometimes a year, if not more, to stabilize. And moving >>>> from an older release is even harder (see for instance recent Skip's from >>>> 9 to 12 experience) >>>> * If they want new stuff they can always use trunk. I believe people are >>>> now more interested in stability and security than new features; because >>>> OFBiz is mature. >>>> * We will more follow how most Apache projects evolve (most don't do major >>>> releases each year). And it should be easier to plan things (something we >>>> really lack, something users can refer to), like some other Apache >>>> projects do. >>>> * Since we decided to let alive only the 3 last releases, this would >>>> greatly increase the releases life span... >>>> * Because we decided to remove specialpurpose from releases, new >>>> components should not be a problem (this suppose no new applications level >>>> components, but anyway read below about this convention) >>>> >>>> CONS: >>>> * Less features each year, need to wait more for that, but anyway still >>>> availabe from trunk >>>> >>>> I can't see anything else, I must miss some CONS points :). >>>> >>>> What do you think? Of course this would not be set in stone. If a major >>>> new feature needs to be released, the convention could be left aside for a >>>> new major release. >>>> >>>> Jacques >>
