Hi Jacques:
For what it is worth: Best OFBiz proposal I've heard in a long time!
Ruth
On 8/6/13 9: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


Reply via email to