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). _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
