[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