This is a good summary of the discussions.

I'm not clear on what "officialize" means. I would prefer to have this release roadmap considered as a general outline, and not something cast in stone. My concern is that it will be taken too literally and future efforts to vary the release schedule will be met with resistance because they don't fit in with the "officialized" road map. In other words, I'm okay with the proposed roadmap, as long as there is some "wiggle room" to do things differently now and then should the need arise.

-Adrian


 On 2/26/2012 3:29 PM, Jacopo Cappellato wrote:
We have recently discussed in a few threads some strategies for the definition 
of a release roadmap for OFBiz; I am summarizing here the main points (old and 
new) because there seems to be a general agreement around them and we should be 
ready to officialize them and then stick to this plan:

* the release roadmap will be time-based rather than feature-based
* every year a new release branch is created on April, generating a new Major 
Release Number in the format YY.MM (this is *not* a release)
* from each active release branch we will release 2 releases every year (approx every 
6 months); the names of the releases will be YY.MM.<aa>  where aa is a two 
digits sequential number (01 is the first release, 02 the second etc..)
* no more than 3 active release branches will be maintained simultaneously; for 
this reason we will close the oldest release branch every year sometimes before 
April (when the new one is created)

An outstanding topic is the following:
* do we still want to wait approx 1 year before releasing the first release of 
a branch?

I don't have a strong preference but maybe a stabilization period of 6 months 
could be enough... but I don't know. In the plan below I am proposing a 
stabilization period of 10 months.

As a result of the above rules, we will release approx 5 releases per year 
considering the following lifecycle of a release branch:
* created in April
* first year: stabilization; no new releases are created
* second year: two releases 01 and 02
* third year: two releases 03 and 04
* fourth year: one release 05 and then the branch is closed

If we name A (oldest), B and C (newest) the three active release branches, then 
we could stick to the following roadmap:

C: new release on February and August
B: new release on March and September
A: new (last) release on April and then closed (when on April the new branch D 
is created)

For example:

2015
Jan
Feb             C1 (after mostly 10 months of stabilization)
Mar             B3
Apr             A5 (last); D is created
May
Jun
Jul
Aug             C2
Sep             B4
Oct
Nov
Dec

2016
Jan
Feb             D1
Mar             C3
Apr             B5 (last); E is created
May
Jun
Jul
Aug             D2
Sep             C4
Oct
Nov
Dec

2016
Jan
Feb             E1
Mar             D3
Apr             C5 (last); F is created
May
Jun
Jul
Aug             E2
Sep             D4
Oct
Nov
Dec

etc...

Kind regards

Jacopo

Reply via email to