This sounds wise to me, indeed we can't really envisoin what we will have in 1 year, unless we try to plan something, even roughly. For instance something like the slim down action, which I believe is done now, right?
Jacques ----- Original Message ----- From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com> To: <dev@ofbiz.apache.org> Sent: Tuesday, August 13, 2013 9:40 AM Subject: Re: [PROPOSAL] New way for releases scheduling > 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 <jacques.le.r...@les7arts.com> > 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" <adrian.c...@sandglass-software.com> >> To: <dev@ofbiz.apache.org> >> 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 >>> > >
