[Gluster-Maintainers] RFC for change in release model

[Aravinda]

regards
Aravinda

On 04/15/2016 03:16 PM, Pranith Kumar Karampuri wrote:
> hi,
>         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 
> on.
>
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 
feature list.
>
> Pranith
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers