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
