[Gluster-Maintainers] RFC for change in release model
avishwan at redhat.com
Fri Apr 15 14:05:52 UTC 2016
On 04/15/2016 03:16 PM, Pranith Kumar Karampuri wrote:
> Yesterday Vijay, Niels and I discussed(#gluster-dev) that
> there has been a tension/conflict between keeping a release stable vs
> maturing new features where users have been giving feedback.
> At the moment if the feature misses a release, for us to get feedback
> from users it generally takes 7-8 months because it needs to get into
> next release. So we want to shorten it by following shorter minor
> release cycles (3months) with some releases termed as long term
> support(LTS) like we have in Ubuntu world(At least that is where I
> first heard it). So the proposal is to have 3.8 as long-term support
> release, 3.9 to be released in September which is not a long-term
> support release. As soon as 4.0 gets released 3.9 based releases will
> stop as all those features will move to 4.0. branch. This will make
> sure that small features won't be backported to already released
> branches. Also we can point enthusiastic users to try the new features
> out in the next release, which is not too far off.
> From a user's perspective people who are not looking for any
> new features should stay on long-term-support branch based releases.
> Where as people who are interested in a new feature can start their
> testing with release where the feature is available whether it is
> going to be long-term-support or not and give us feedback, if they
> like the stability they can even put that in production. Once the
> feature is in a LTS branch they should stick to LTS branches from then
Awesome. +1 for the idea. Also matches with Debian releases (Stable,
Testing and Unstable)
> Please feel free to let us know what you guys think about this. Main
> problem we need to solve is to prevent new features to land in the
> middle of stable release cycles. At the same time not have longer wait
> times for users to give us feedback.
I think we need feature gate/feature flag for every feature. All code
changes for that feature should be behind this gate/flag.
Enabling/Disabling feature should be done by enabling/disabling in
> maintainers mailing list
> maintainers at gluster.org
More information about the maintainers