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 <[email protected]> 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 > > > > [email protected] <mailto:[email protected]> > > > > > > > > > > > > > > > > _______________________________________________ > > > > maintainers mailing list > > > > [email protected] > > > > http://lists.gluster.org/mailman/listinfo/maintainers > > > > > > > _______________________________________________ > > > maintainers mailing list > > > [email protected] > > > http://lists.gluster.org/mailman/listinfo/maintainers > >
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
