[Gluster-Maintainers] Release schedule minor updates question

Mon Feb 27 20:39:56 UTC 2017

On Mon, Feb 27, 2017 at 01:53:56PM -0500, Dustin Black wrote:
> 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*
>     |            |

Yes, that is what I mean. Thanks!
Niels

> 
> 
> >
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170227/f4247f2e/attachment-0001.sig>