[Gluster-Maintainers] Release schedule minor updates question

[Niels de Vos]

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).

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/7fed19bb/attachment-0001.sig>