On Tue, Jun 14, 2016 at 5:38 PM, Pranith Kumar Karampuri < [email protected]> 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 <[email protected]> wrote: > >> >> >> On Sat, Jun 11, 2016 at 10:55 AM, Atin Mukherjee <[email protected]> >> 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 | [email protected] | Gluster Community Lead >> >> _______________________________________________ >> maintainers mailing list >> [email protected] >> http://www.gluster.org/mailman/listinfo/maintainers >> >> > > > -- > Pranith > -- Amye Scavarda | [email protected] | Gluster Community Lead
_______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
