[Gluster-Maintainers] Release scheduling and lifecycle of versions

Aravinda avishwan at redhat.com
Fri Jun 10 06:50:28 UTC 2016


Shared visualizations about release process alternatives(May 13th). 
Please check the attachments in the below link
http://www.gluster.org/pipermail/gluster-devel/2016-May/049533.html

regards
Aravinda

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
>
>   (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)
>
>   ----.
>   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.
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160610/86923e4c/attachment.html>


More information about the maintainers mailing list