[Gluster-Maintainers] Release schedule minor updates question

[Dustin Black]

On Mon, Feb 27, 2017 at 1:06 PM, Niels de Vos <ndevos at redhat.com> wrote:

> On Mon, Feb 27, 2017 at 11:25:11AM -0500, Shyam wrote:
> > On 02/27/2017 11:14 AM, Dustin Black wrote:
> > > I'm working on an update to the release schedule page [1] and have a
> > > question about the minor updates schedule for the active version.
> >
> > Awesome, thanks!
> >
> > >
> > > We have the 10th, 20th, and 30th of the month marked for minor updates
> > > to active versions. As of the 3.10 release the active versions should
> be
> > > only 3.8 and 3.10 (pre-3.8 version are all EOL and with this cycle
> there
> > > are no active STM versions).
> > >
> > > So for minor maintenance releases, which dates should be reflected for
> > > each of the 3.8 and 3.10 versions?
> >
> > 3.10: 30th (as we released end of Feb. I am tying this to the month after
> > that)
> >
> > >
> > > It would probably be best to update the webpage so that the section
> > > about minor updates isn't tied to version numbers so that it doesn't
> > > require an update with each release. Is there a standard way I could
> > > describe how we assign the update dates to the currently maintained
> > > versions?
> >
> > This is a good idea, so that we/I do not tie this up as a month since
> the .0
> > was released.
> >
> > My initial thought here would be,
> > 10th - LTM1
> > 20th - any open SMT
> > 30th - LTM2
> >
> > This is to give time between each minor release, for any/all activity.
> > Unfortunately LTM1/2 will keep switching in this scheme.
> >
> > Another, thought would be to do a fixed date for all LTMs. If a fix
> appears
> > in one LTM there is a good or even chance it will in the other, so
> possibly
> > fixing the LTM date can be a good idea, for the
> development/testing/upgrade
> > cycles. (and, as a result a fixed date for the STM as well.)
> >
> > The downside of this is that, packaging of both LTMs fall around the same
> > time, possibly stretching the time required by this team to make the
> release
> > happen. If the packaging team is fine with this, the I would choose this
> > over different dates for the LTM.
> >
> > In the latter scheme, we can choose 10th or the 30th for the LTM,
> possibly
> > the 10th as that is established for 3.8, for some duration and we can
> carry
> > that forward. Also, choose 20th for the STM.
>
> I would say that once a LTM is released on the 10th or the 30th, that
> date will stay for the lifetime of the minor updates. This makes it more
> predictable for users of that LTM.
>
> We will have to update the page with the release dates (and approx. EOL)
> for all major versions anyway, in that table the day for the minor
> release is listed too. No need to have the version numbers in the
> describing paragraph(s).
>

I have an update for the release table staged already; I'm just waiting to
answer this question before the pull request.

The table right now doesn't have the minor update day in it directly --
that info is in the text and bullet points above the table. But, maybe this
is a way to solve the issue. We can just put the minor update day right
there in the table with the release version. Something like this:

## Release Status

| Version  | Status          | Release Date    | Maintenance Day | EOL
Version | EOL Date   |
| --------
|:---------------:|:---------------:|:---------------:|:-----------:|:----------:|
| 3.5      | EOL             | 2014-05-07      |                 | 3.8
    | 2016-06-14 |
| 3.6      | EOL             | 2014-10-31      |                 | 3.9
    | 2016-11-23 |
| 3.7      | EOL             | 2015-05-15      |                 | 3.10
   | 2017-02-24 |
| 3.8      | LTM             | 2016-06-14      | 10th            | 3.12
   |            |
| 3.9      | EOL             | 2016-11-23      |                 | 3.10
   | 2017-02-24 |
| **3.10** | **LTM**         | **2017-02-27**  | 30th            | **n+4**
    |            |
| *3.11*   | *Planned STM*   | *about 2017-05* |                 | 3.12
   |            |
| *3.12*   | *Planned LTM*   | *about 2017-08* |                 | *n+4*
    |            |


>
> Thanks,
> Niels
>
>
> >
> > >
> > >
> > > [1] https://www.gluster.org/community/release-schedule/
> > >
> > > Dustin Black, RHCA
> > > Senior Architect, Software-Defined Storage
> > > Red Hat, Inc.
> > > (o) +1.212.510.4138  (m) +1.215.821.7423
> > > dustin at redhat.com <mailto:dustin at redhat.com>
> > >
> > >
> > >
> > > _______________________________________________
> > > maintainers mailing list
> > > maintainers at gluster.org
> > > http://lists.gluster.org/mailman/listinfo/maintainers
> > >
> > _______________________________________________
> > maintainers mailing list
> > maintainers at gluster.org
> > http://lists.gluster.org/mailman/listinfo/maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170227/ea0c67f1/attachment.html>