[Gluster-Maintainers] Release scheduling and lifecycle of versions

Atin Mukherjee amukherj at redhat.com
Sat Jun 11 17:55:34 UTC 2016



On 06/10/2016 07:51 AM, Niels de Vos wrote:
> After several weeks of discussions on this list, in the weekly meeting
> and ad-hoc IRC chats, I have come to the following understanding of the
> release schedule, lifecyle and minor updates.
> 
> ## What we want to address
> 
> 1. regular releases, predictable cycle for users and other projects
> 2. faster "go to market" with new features, receive feedback from users
> 3. stable version(s) for 'happily running, no risk' deployments
> 4. active releases can do monthly bugfix updates (see backport criteria)
> 
> 
> ## Results of several rounds of discussion
> 
> It seems that a 3 month release cycle is the most attractive. Each
> alternating major release would be a Long-Term-Support (LTS) one, the
> others are short living versions for users that are eager to test out a
> new feature.
> 
> 
> ## Three stable/LTS versions, 1.5 years of bugfixes
> 
> In dates and versions, this results in something like:
> 
>  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.14 goes GA (2017-12)
>  3.9: EOL when 3.10 goes GA (2016-12)
>  3.10 [LTS]: EOL when 3.16 goes GA (2018-06)
>  3.11: EOL when 3.12 goes GA (2017-06)
>  3.12 [LTS]: EOL when 3.18 goes GA (2018-12)
>  3.13: EOL when 3.13 goes GA
>  3.14 [LTS]: EOL when 3.20 goes GA
> 
>  (one of the 3.x releases will be called 4.0, I do not want to predict
>   when that is ready and leave that up to the 4.0 team)
> 
> And, 'visualized':
> 
>  ----.
>  3.5 |
>  -----------.
>         3.6 |
>  ------------------.
>                3.7 |
>  ----------------------------------------------.
>      |                   3.8                   |
>      '------.------.---------------------------'
>             | 3.9  |
>      :      '------+-----------------------------------------.
>                    |                   3.10                  |
>      :      :      '------.------.---------------------------'
>                           | 3.11 |
>      :      :      :      '------+-------------------------------------
>                                  |                   3.12
>      :      :      :      :      '------.------.-----------------------
>                                         | 3.13 |
>      :      :      :      :      :      '------+-----------------------
>                                                |                   3.14
>      :      :      :      :      :      :      '------.------.---------
>                                                       | 3.15 |
>      :      :      :      :      :      :      :      '------+---------
>                                                              |     3.16
>      :      :      :      :      :      :      :      :      '---------
> 
>   2016-06   :   2016-12   :   2017-06   :   2017-12   :   2018-06
> 
>          2016-09       2017-03       2017-09       2018-03
> 
> 
> ## 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

+1

> 
>  (one of the 3.x releases will be called 4.0, I do not want to predict
>   when that is ready and leave that up to the 4.0 team)

Most probably it'd be around 3.12ish as per my prediction.

> 
>  ----.
>  3.5 |
>  -----------.
>         3.6 |
>  ------------------.
>                3.7 |
>  --------------------------------.
>      |            3.8            |
>      '------.------.-------------'
>             | 3.9  |
>      :      '------+---------------------------.
>                    |           3.10            |
>      :      :      '------.------.-------------'
>                           | 3.11 |
>      :      :      :      '------+---------------------------.
>                                  |           3.12            |
>      :      :      :      :      '------.------.-------------'
>                                         | 3.13 |
>      :      :      :      :      :      '------+-----------------------
>                                                |            3.14
>      :      :      :      :      :      :      '------.------.---------
>                                                       | 3.15 |
>      :      :      :      :      :      :      :      '------+---------
>                                                              |     3.16
>      :      :      :      :      :      :      :      :      '---------
> 
>   2016-06   :   2016-12   :   2017-06   :   2017-12   :   2018-06
> 
>          2016-09       2017-03       2017-09       2018-03
> 
> 
> 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.

What would be the frequency of the z stream releases for LTS? Should we
keep it flexible and decide based on the volume of incoming fixes?

> 
> Any suggestions for modifications or clarification needed before this
> can be transferred to a good looking webpage (by Amye?) on gluster.org?
> 
> Thanks,
> Niels
> 
> 
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
> 


More information about the maintainers mailing list