<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 10:55 AM, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 06/10/2016 07:51 AM, Niels de Vos wrote:<br>
</span><div><div class="h5">> After several weeks of discussions on this list, in the weekly meeting<br>
> and ad-hoc IRC chats, I have come to the following understanding of the<br>
> release schedule, lifecyle and minor updates.<br>
><br>
> ## What we want to address<br>
><br>
> 1. regular releases, predictable cycle for users and other projects<br>
> 2. faster "go to market" with new features, receive feedback from users<br>
> 3. stable version(s) for 'happily running, no risk' deployments<br>
> 4. active releases can do monthly bugfix updates (see backport criteria)<br>
><br>
><br>
> ## Results of several rounds of discussion<br>
><br>
> It seems that a 3 month release cycle is the most attractive. Each<br>
> alternating major release would be a Long-Term-Support (LTS) one, the<br>
> others are short living versions for users that are eager to test out a<br>
> new feature.<br>
><br>
><br>
> ## Three stable/LTS versions, 1.5 years of bugfixes<br>
><br>
> In dates and versions, this results in something like:<br>
><br>
> 3.5: EOL when 3.8 goes GA (2016-06)<br>
> 3.6: EOL when 3.9 goes GA (2016-09)<br>
> 3.7: EOL when 3.10 goes GA (2016-12)<br>
> 3.8 [LTS]: EOL when 3.14 goes GA (2017-12)<br>
> 3.9: EOL when 3.10 goes GA (2016-12)<br>
> 3.10 [LTS]: EOL when 3.16 goes GA (2018-06)<br>
> 3.11: EOL when 3.12 goes GA (2017-06)<br>
> 3.12 [LTS]: EOL when 3.18 goes GA (2018-12)<br>
> 3.13: EOL when 3.13 goes GA<br>
> 3.14 [LTS]: EOL when 3.20 goes GA<br>
><br>
> (one of the 3.x releases will be called 4.0, I do not want to predict<br>
> when that is ready and leave that up to the 4.0 team)<br>
><br>
> And, 'visualized':<br>
><br>
> ----.<br>
> 3.5 |<br>
> -----------.<br>
> 3.6 |<br>
> ------------------.<br>
> 3.7 |<br>
> ----------------------------------------------.<br>
> | 3.8 |<br>
> '------.------.---------------------------'<br>
> | 3.9 |<br>
> : '------+-----------------------------------------.<br>
> | 3.10 |<br>
> : : '------.------.---------------------------'<br>
> | 3.11 |<br>
> : : : '------+-------------------------------------<br>
> | 3.12<br>
> : : : : '------.------.-----------------------<br>
> | 3.13 |<br>
> : : : : : '------+-----------------------<br>
> | 3.14<br>
> : : : : : : '------.------.---------<br>
> | 3.15 |<br>
> : : : : : : : '------+---------<br>
> | 3.16<br>
> : : : : : : : : '---------<br>
><br>
> 2016-06 : 2016-12 : 2017-06 : 2017-12 : 2018-06<br>
><br>
> 2016-09 2017-03 2017-09 2018-03<br>
><br>
><br>
> ## Two stable/LTS versions, 1 year of bugfixes<br>
><br>
> Looking at the diagram makes me wonder if this really is a sane approach<br>
> that we can promise to our users. When 3.13 (or 4.x) gets released, we<br>
> would have 4 active versions. At the moment we are already struggling<br>
> with three active versions, so I doubt we can really do that. So, here a<br>
> variation, and my suggestion to keep two stable releases instead of<br>
> three:<br>
><br>
> 3.5: EOL when 3.8 goes GA (2016-06)<br>
> 3.6: EOL when 3.9 goes GA (2016-09)<br>
> 3.7: EOL when 3.10 goes GA (2016-12)<br>
> 3.8 [LTS]: EOL when 3.12 goes GA (2017-06)<br>
> 3.9: EOL when 3.10 goes GA (2016-12)<br>
> 3.10 [LTS]: EOL when 3.14 goes GA (2017-12)<br>
> 3.11: EOL when 3.12 goes GA (2017-06)<br>
> 3.12 [LTS]: EOL when 3.16 goes GA (2018-06)<br>
> 3.13: EOL when 3.13 goes GA<br>
> 3.14 [LTS]: EOL when 3.18 goes GA<br>
<br>
</div></div>+1<br>
<span class=""><br>
><br>
> (one of the 3.x releases will be called 4.0, I do not want to predict<br>
> when that is ready and leave that up to the 4.0 team)<br>
<br>
</span>Most probably it'd be around 3.12ish as per my prediction.<br>
<div><div class="h5"><br>
><br>
> ----.<br>
> 3.5 |<br>
> -----------.<br>
> 3.6 |<br>
> ------------------.<br>
> 3.7 |<br>
> --------------------------------.<br>
> | 3.8 |<br>
> '------.------.-------------'<br>
> | 3.9 |<br>
> : '------+---------------------------.<br>
> | 3.10 |<br>
> : : '------.------.-------------'<br>
> | 3.11 |<br>
> : : : '------+---------------------------.<br>
> | 3.12 |<br>
> : : : : '------.------.-------------'<br>
> | 3.13 |<br>
> : : : : : '------+-----------------------<br>
> | 3.14<br>
> : : : : : : '------.------.---------<br>
> | 3.15 |<br>
> : : : : : : : '------+---------<br>
> | 3.16<br>
> : : : : : : : : '---------<br>
><br>
> 2016-06 : 2016-12 : 2017-06 : 2017-12 : 2018-06<br>
><br>
> 2016-09 2017-03 2017-09 2018-03<br>
><br>
><br>
> Providing bugfixes for a LTS release for a year seems like a suitable<br>
> middle road. If other projects/organizations want to support a certain<br>
> version longer, they can do so themselves or step up and contribute a<br>
> maintainer to our community.<br>
><br>
><br>
> I expect that the number of patches in the stable releases get reduced A<br>
> LOT compared to the current 3.7 version. With regular releases there<br>
> should not be a need to backport complex patches or features.<br>
> Maintainance of a stable release should be a very boring and simple<br>
> task.<br>
<br>
</div></div>What would be the frequency of the z stream releases for LTS? Should we<br>
keep it flexible and decide based on the volume of incoming fixes?<br>
<span class="im HOEnZb"><br>
><br>
> Any suggestions for modifications or clarification needed before this<br>
> can be transferred to a good looking webpage (by Amye?) on <a href="http://gluster.org" rel="noreferrer" target="_blank">gluster.org</a>?<br>
><br>
> Thanks,<br>
> Niels<br></span></blockquote></div><br clear="all"><div><br></div><div>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.</div><div>LTS means Long Term Support, and Niels outlines this. </div><div>Are we currently providing, as <a href="http://gluster.org">gluster.org</a>, something that we would declare 'S' in LTS? </div><div>How does that change/improve/decline with this new proposed process? We should discuss before moving this to -users/-devel. </div><div><br></div><div>I'm also with Kaleb on his comments about how we establish a schedule. </div><div>-- amye </div><div><br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Amye Scavarda | <a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a> | Gluster Community Lead</div></div>
</div></div>