[Gluster-Maintainers] Release scheduling and lifecycle of versions

[Dustin Black]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160801/e9ea193c/attachment.html>