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