[Gluster-Maintainers] Release scheduling and lifecycle of versions

[Dustin Black]

On Mon, Aug 1, 2016 at 3:06 PM, Dustin Black <dblack at redhat.com> wrote:
>
> On Wed Jun 15 13:07:20 UTC 2016, Niels de Vos wrote:
> > On Wed, Jun 15, 2016 at 07:55:09AM -0500, Ric Wheeler wrote:
> > > On 06/14/2016 10:59 PM, Richard Fontana wrote:
> > > > On Tue, Jun 14, 2016 at 11:02:12PM -0400, Kaleb Keithley wrote:
> > > >
> > > > > But we don't need to guess, we can just ask our resident legal
> > > > > counsel, who wi ll tell us if there are any implications to
calling
> > > > > our planned long life cycle release of Community GlusterFS an "LTS
> > > > > release."
> > > > >
> > > > > Off hand I wouldn't expect there to be, but––
> > > > >
> > > > > Richard (and Ric) what, if any, implications are there? Should we
pick a different name?
> > > > No objection to "LTS" from me. I do not consider the 'S" to imply
> > > > "commercial support" if that's what the concern is (but even if it
> > > > did, that would not create any legal issue). I defer to Ric on
whether
> > > > there could be some non-legal concern around using "LTS".
> > > >
> > > > Richard
> > >
> > >
> > > The kernel calls its long term upstream versions "stable" releases or
> > > branches. LTS could stand for long term stable I suppose :)
> > >
> > > I don't think that we really care much, what we call the community
branches
> > > should be a community call. I would agree that avoiding "supported"
in the
> > > title is probably a good thing, but don't lose sleep over those terms.
> >
> > Oh, yes, great idea!
> >
> >    LTS: Long Term Stable - 1 year of bugfixes
> >    STS: Short Term Stable - 3 months of bugfixes
> >
> > We should use that :D
> > Niels
>
> How about "LTM: Long Term Maintenance" and "STM: Short Term Maintenance"?
It keeps the spirit without the possible conflicts or confusion related to
"support" or what the communities may (or may not) expect from the
similarity to Ubuntu's acronyms.
>
> -Dustin

Building on the ASCII diagrams that Niels started (and continuing with the
"LTM" terminology that I've proposed and prefer), I would like to devise
graphics for the release website that explain the ongoing release schedule
in a way that doesn't need constant updating with release numbers and dates
(though we would likely maintain a separate table of actual and planned
releases).

I think it's best if this is broken into two sections: pre-3.8 and
post-3.8. The first section necessarily needs release numbers so that we
can properly document the retirement of the old release schedule. It would
look something like the below.

Current Releases up to 3.7:

+----+
 3.5 | *EOL at 3.8 release
+----+-----+
     : 3.6 | *EOL at 3.9 release
+----------+-----+
     :     : 3.7 | *EOL at 3.10 release
+----------------+
     :     :     :
     :     :     :
     +-----------------+
     | 3.8 :     :
     +-----+-----------+
           | 3.9 :
           +-----+-----+
                 | 3.10
                 +-----+


The second section would graphically represent the ongoing 3-month release
schedule with every other release a LTM release. I think showing a roughly
18 month spread is enough to get the point across well.


 Release and Maintenance plan for 3.8+:

 +-----------------------+
 | Release 1 LTM         |
 +-----+-----+-----------+
 :     | R2  |           :
 :     +-----------------------------+
 :     :     | Release 3 LTM         |
 :     :     +-----+-----+-----------+
 :     :     :     | R4  |           :
 :     :     :     +-----------------------------+
 :     :     :     :     | Release 5 LTM         |
 :     :     :     :     +-----+-----+-----------+
 :     :     :     :     :     | R6  |
 :     :     :     :     :     +-----+
 :     :     :     :     :           :
 0   +3mos +6mos +9mos +12mos      +18mos      ...



Labeling the releases as numbers above is probably a problem, but I was
struggling to find a better way to denote the release progression. Ideas?

Obviously this will all look better and will more clearly illustrate the
release schedule when nicely rasterized, which I will work on.

Just in case the ASCII art gets squashed by your e-mail clients, I've
attached the above as a pdf file.

Cheers!
-Dustin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160801/ad2cb59a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled ASCII Diagram.pdf
Type: application/pdf
Size: 37070 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160801/ad2cb59a/attachment-0001.pdf>