Thank you Adrian, I agree with you and should not have used the word "official" because it is misleading; let's simply say that there is consensus in the dev list to attempt to stick to this plan; of course we will review it over time and change it if required, or maybe simply ignore it if it will not prove to be useful over time.
Jacopo On Feb 26, 2012, at 4:37 PM, Adrian Crum wrote: > 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 >>
