[Gluster-Maintainers] Release scheduling and lifecycle of versions

[Kaleb Keithley]

<top post>
I vote for this.

How do we ensure that all following releases are made on schedule?
</top post>


----- Original Message -----
> From: "Vijay Bellur" <vbellur at redhat.com>
> To: "Niels de Vos" <ndevos at redhat.com>
> Cc: "GlusterFS Maintainers" <maintainers at gluster.org>
> Sent: Friday, June 10, 2016 10:37:33 PM
> Subject: Re: [Gluster-Maintainers] Release scheduling and lifecycle of	versions
> 
> On Thu, Jun 9, 2016 at 10:21 PM, Niels de Vos <ndevos at redhat.com> wrote:
> > ## Two stable/LTS versions, 1 year of bugfixes
> >
> > Looking at the diagram makes me wonder if this really is a sane approach
> > that we can promise to our users. When 3.13 (or 4.x) gets released, we
> > would have 4 active versions. At the moment we are already struggling
> > with three active versions, so I doubt we can really do that. So, here a
> > variation, and my suggestion to keep two stable releases instead of
> > three:
> >
> >  3.5: EOL when 3.8 goes GA (2016-06)
> >  3.6: EOL when 3.9 goes GA (2016-09)
> >  3.7: EOL when 3.10 goes GA (2016-12)
> >  3.8 [LTS]: EOL when 3.12 goes GA (2017-06)
> >  3.9: EOL when 3.10 goes GA (2016-12)
> >  3.10 [LTS]: EOL when 3.14 goes GA (2017-12)
> >  3.11: EOL when 3.12 goes GA (2017-06)
> >  3.12 [LTS]: EOL when 3.16 goes GA (2018-06)
> >  3.13: EOL when 3.13 goes GA
> >  3.14 [LTS]: EOL when 3.18 goes GA
> >
> 
> This seems like a good plan to me.
> 
> >
> > Providing bugfixes for a LTS release for a year seems like a suitable
> > middle road. If other projects/organizations want to support a certain
> > version longer, they can do so themselves or step up and contribute a
> > maintainer to our community.
> >
> >
> > I expect that the number of patches in the stable releases get reduced A
> > LOT compared to the current 3.7 version. With regular releases there
> > should not be a need to backport complex patches or features.
> > Maintainance of a stable release should be a very boring and simple
> > task.
> 
> +1
> 
> >
> > Any suggestions for modifications or clarification needed before this
> > can be transferred to a good looking webpage (by Amye?) on gluster.org?
> >
> 
> A post on -devel and -users explaining this release cadence/strategy
> and soliciting feedback would be necessary before we publish on
> gluster.org.
> 
> -Vijay
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>