[Gluster-Maintainers] RFC for change in release model

Raghavendra Talur rtalur at redhat.com
Fri Apr 15 10:43:01 UTC 2016


On Fri, Apr 15, 2016 at 3:16 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> 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.
>

Does this mean we will have to maintain only two releases at a time? One
LTS and one non-LTS.
What will happen to 3.6 and 3.7?


>        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.
>
>         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.
>
> Pranith
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160415/a945861a/attachment-0001.html>


More information about the maintainers mailing list