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 >
