[Gluster-Maintainers] Release scheduling and lifecycle of versions
Amye Scavarda
amye at redhat.com
Wed Jun 15 00:58:24 UTC 2016
On Tue, Jun 14, 2016 at 5:38 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:
> hi,
> Some of our managers were cautioning us to use the term LTS with
> care as it means something else in ubuntu world where LTS is how they make
> money by providing support. I see that quite a few open source projects
> have similar release cadence but they don't call them LTS. They call them
> stable branches. May be it makes sense to call them stable branches and
> feature branches rather than LTS/non-LTS? Suggestions for other names is
> welcome. At least we need to clear any confusion that we are not looking to
> make money out of the LTS branches :-D. Different name for the branches is
> preferable.
>
> This is what I was cautioning around:
## 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.
We should use a different word to make clear what we're actually offering.
I am fine with 'stable', 'currently receiving patches', whatever. The S in
Support, I feel, should be a downstream concern, and I am not sure we are
making that clear within ourselves.
-- a
On Wed, Jun 15, 2016 at 1:06 AM, Amye Scavarda <amye at redhat.com> wrote:
>
>>
>>
>> On Sat, Jun 11, 2016 at 10:55 AM, Atin Mukherjee <amukherj at redhat.com>
>> wrote:
>>
>>>
>>>
>>> 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
>>>
>>
>>
>> So I've caught up on (I think) - most of the discussions that have been
>> happening in different places but I'm still missing a critical piece in
>> here.
>> LTS means Long Term Support, and Niels outlines this.
>> Are we currently providing, as gluster.org, something that we would
>> declare 'S' in LTS?
>> How does that change/improve/decline with this new proposed process? We
>> should discuss before moving this to -users/-devel.
>>
>> I'm also with Kaleb on his comments about how we establish a schedule.
>> -- amye
>>
>> Amye Scavarda | amye at redhat.com | Gluster Community Lead
>>
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org
>> http://www.gluster.org/mailman/listinfo/maintainers
>>
>>
>
>
> --
> Pranith
>
--
Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160614/379397e8/attachment.html>
More information about the maintainers
mailing list