[Gluster-Maintainers] Release scheduling and lifecycle of versions

[Vijay Bellur]

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