[Gluster-Maintainers] Release scheduling and lifecycle of versions
Niels de Vos
ndevos at redhat.com
Fri Jun 10 10:23:55 UTC 2016
On Fri, Jun 10, 2016 at 12:20:28PM +0530, Aravinda wrote:
> 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
Yes, and thread was also part of the discussions that I used for input.
In my ascii diagram I tried to merge the timeline of the stable/LTS
releases with the short living feature update releases. You have kept
them seperate in your diagrams. I hoped to make it a little clearer how
the two different release streams are weaved together, not sure if I
succeeded in that. If you're using an email reader that does not use
mono-spaced fonts, it most definitely doesnt make sense. In that case,
check the email archives instead, the ascii diagram should look better
there:
http://thread.gmane.org/gmane.comp.file-systems.gluster.maintainers/880
I dont know how you created the diagrams, but I could do a .png version
too if that is more helpful. Not sure if we can use MarkDown to create
it, that would make it easy to get it on the website too.
Thanks,
Niels
>
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160610/57d5b312/attachment.sig>
More information about the maintainers
mailing list