<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Shared visualizations about release process alternatives(May
13th). Please check the attachments in the below link<br>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/pipermail/gluster-devel/2016-May/049533.html">http://www.gluster.org/pipermail/gluster-devel/2016-May/049533.html</a><br>
</tt>
<pre class="moz-signature" cols="72">regards
Aravinda</pre>
<div class="moz-cite-prefix">On 06/10/2016 07:51 AM, Niels de Vos
wrote:<br>
</div>
<blockquote
cite="mid:20160610022123.GB29939@ndevos-x240.usersys.redhat.com"
type="cite">
<pre wrap="">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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
maintainers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:maintainers@gluster.org">maintainers@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/maintainers">http://www.gluster.org/mailman/listinfo/maintainers</a>
</pre>
</blockquote>
<br>
</body>
</html>