[Gluster-users] [Gluster-devel] Idea: Alternate Release process
oleksandr at natalenko.name
Wed May 11 21:10:24 UTC 2016
My 2 cents on timings etc.
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
* "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
New release happens every 8 weeks. Those 8 weeks include:
* merge window for 3 weeks, during this time all ready features get merged
* 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
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
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.
* frequent releases with new features that do not break backward
* max 2 stable branches supported simultaneously;
* guaranteed LTS branch with guaranteed upgrade to new LTS.
* 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).
More information about the Gluster-users