[Gluster-devel] Idea: Alternate Release process

[Oleksandr Natalenko]

My 2 cents on timings etc.

Rationale:

1. deliver new features to users as fast as possible to get the feedback;
2. leave an option of using LTS branch for those who do not want update too 
often.

Definition:

* "stable release" — .0 tag that receives critical bugfixes and security 
updates for 16 weeks;
* "LTS" — .0 tag that receives critical bugfixes and security updates for 1 
year;

New release happens every 8 weeks. Those 8 weeks include:

* merge window for 3 weeks, during this time all ready features get merged 
into master;
* feature freeze on -rc1 tagging;
* 5 weeks of testing, bugfixing and preparing new features;
* tagging .0 stable release.

Example (imaginary versions and dates):

March 1 — 5.0 release, merge window opens
March 22 — 6.0-rc1 release, merge window closes, feature freeze, new -rc each 
week
May 1 — 6.0 release, merge window opens, 5.0 still gets fixes
May 22 — 7.0-rc1 release
July 1 — 7.0 release, merge window closes, no more fixes for 5.0, 6.0 still 
gets fixes
...
September 1 — 8.0 release, LTS, EOT is Sep 1, next year.
...

Backward compatibility should be guaranteed during the time between two 
consecutive LTSes by excessive using of op-version. The user should have a 
possibility to upgrade from one LTS to another preferably with no downtime. 
LTS+1 is not guaranteed to backward compatible with LTS-1.

Pros:

* frequent releases with new features that do not break backward 
compatibility;
* max 2 stable branches supported simultaneously;
* guaranteed LTS branch with guaranteed upgrade to new LTS.

Cons:

* no idea what to do with things that break backward compatibility and that 
couldn't be implemented within op-version constraints (except postponing them 
for too much).