[policy, no patch] Consider a three-day instead of one-day window for beta/rc and bug fix releases

I'd suggest, with my "community working group" chair hat on, that this seems sane. Providing a bit of breathing room around this should be good for the mental health of both our core committers and our core contributors striving to get their work in.

Thanks catch. Good idea in my view.

+1

dawehner: no it'd be the same as now, just no promises that it's on a Wednesday.

IMHO noone expects beta/RCs/alphas/gammas to be out at any given day, they are there when they are ready to be so.

I'm not sure whether people though for stable releases plan to be on a certain day. Practically though, as long its not a security issue, there is no high pressure to get those updates applied, so a different release day is fine totally as well.

I have mixed feelings about this proposal. While I think it would be fine for us to announce that (for example), 8.1.0-rc1 will be released sometime the week of April 4, it would still be good to announce the exact date a few days in advance, so contributors and committers can plan. For example, we could announce on April 4 that the RC would come out April 7 based on our schedules.

However, I'm not sure that's the case for patch releases. I suspect that the release window for patch releases is probably helpful for organizations, so maybe we should get feedback outside the core issue queue before we consider changing that.

However, I disagree with one thing:

Having a single day deadline means patches that might have got into a beta, don't because of lack of committer time despite being RTBC. And conversely patches that might not be quite ready the day before can/have been rushed in to hit the deadline. This happens just about every core milestone that I can remember. We have a policy of 'either on or off the train as it leaves the station', but sometimes release days feel like there are people either running in front of the train and/or behind it on the tracks as it leaves risking personal injury to either get on or get out of the way, and some others with their coats/bags trapped in the doors.

Having a week deadline instead of a day deadline does not change that. At some point, we need to freeze the code and get a release out. It's totally reasonable for a beta or RC for us to decide to make exceptions or move the window based on committer availability/a certain high-priority issue/etc., like we did yesterday. (A couple issues were committed during the freeze, and we moved the freeze window later than it was originally announced.) However, if we set the expectation that we will just just keep moving the release window until the RTBC queue is empty, or that it is dependent on what changes are ready, that actually puts far more pressure on contributors (to sprint tirelessly for a whole week to get as much as they can done before the wire, rather than setting the expectation that they are done at midnight on Tuesday) and especially on committers (to clear the entire RTBC queue, to make exceptions for everyone's favorite patch, to postpone and postpone the release, to not have a hard commit freeze). So it becomes an exhausting week instead of an exhausting day.

Also the other downside to not just doing Wednesday is that then we have to discuss every month when the window is going to be, which adds more work. So I'd prefer to default to Wednesday always, but be flexible about moving it if someone needs it moved, and that person surfaces the need before the release window is announced on g.d.o/core the Friday before.

So we would modify the release schedule to say:

Week of April 4, 2016: 8.1.0-rc1 released. Final patch release of Drupal 8.

And then the g.d.o/core announcement becomes:

Drupal core release window beginning Wednesday, April 6, 2016

...blah blah blah patch release...Drupal 8.1.0-rc1 will also be released between April 6 and 8 in preparation for the scheduled release of 8.1.0 on April 20th.

To ensure a reliable release window for the patch and rc releases, there will be a Drupal 8.0.x and 8.1.x commit freeze beginning 00:00 to 23:30 UTC on Wednesday, March 02. (For the release candidate, this freeze may be extended to the following day as needed.) Now is a good time to update your development/staging servers to the latest 8.0.x-dev or 8.1.x-dev code and help us catch any regressions in advance. If you do find any regressions, please report them in the issue queue. Thanks!

And if we know in advance that (e.g.) neither catch nor I is available on April 6, then we just move the whole shebang to April 7 in that announcement as well.

Note that in #7, I am still starting the commit freeze midnight UTC Wednesday to set expectations. But I leave open the option of us deciding on Wednesday as a committer team that we will commit RTBCs Wednesday and release Thursday or Friday instead.

What I don't want to happen though is people asking us to move the freeze later and later, to make exceptions, or to expect the whole RTBC queue to be addressed before we create a release. The deadline does not change for issue contributors. We just give ourselves more breathing room for release preparation as committers.

This policy also applies to 8.1.x, so moving back.

I updated things for beta/rc.

The outstanding question then is whether to consider it for patch releases. Patch releases are less overhead, and unlike sec releases, they do not have to be a particular time of day. I think there is value for our userbase in having them on a set day, so I would suggest leaving them as-is for now. Especially if we can eliminate the requirement that D7 and D8 share a front page post about bugfix releases.

The point (according to the policy at least) is so that "site administrators can know in advance which days they should be on the look out for" a release.

Per the current policy:
https://www.drupal.org/documentation/version-info

Which was updated based on:
https://groups.drupal.org/node/260803
but before that it was still Wednesdays....

Which in turn was discussed in:
https://groups.drupal.org/node/150854
and received a lot of positive feedback, but it's unclear how much of that was for the predictability of always having the release on a particular day, versus having monthly releases at all.

I think maybe the next step is to get feedback from people who created that policy and from people who actually run sites? We could post on g.d.o/core or something.

I really do actually prefer having a fixed, specific schedule over having a release looming over my head for a whole week and open to negotiation/pressure. I updated the title and summary to the tighter window as described in #7: still starting at a fixed time, but with more than 24h of leeway for release managers' timezones/personal schedules/etc.

I posted this announcement: https://groups.drupal.org/node/509883

I asked for feedback by April 1. If there are no concerns before then, we can use the proposed schedule for the April patch release window.

it's probably nice not to have core releases on Friday

Please exclude Friday from release day, better delay til next Mon

Yeah +1 to not releasing on a Friday. The smaller the window the better in my opinion.

I also feel strongly about security releases never changing from a fixed day, I hope this doesn't become a precedent in the future to also move security releases to a more flexible release window.

I think coordinated releases even across bugfix and security fixes is useful because you update your core bugfix release on Tue then a security release comes up on Wed for the modules you use, and then you again go into updating, etc. If those came out the same day, its easier to review what to update and you can do all at once. Which I think is the benefit of having them come out all at once. I can see how its hard to keep to a more stricter schedule though on the release side, so those should be weighted against the user benefit.

+1 #19, 20, 23. Smaller window the better, Wednesday in the middle (per catch), all together now!

So maybe we can start the official window 12h earlier and end it 12h later? Noon UTC Tuesday to noon UTC Thursday.

I've occasionally pushed releases to Thursday or even Friday in the past, for example:

https://groups.drupal.org/node/421278
https://groups.drupal.org/node/448448

No one ever complained :)

Please consider to Announce that there are no announcements.

Updated the summary slightly to make it clear that the beta/rc window is mostly the same as the patch window.

Marking RTBC since this seems to have consensus. We used a window like this for beta2 and I announced such a window for rc1 as well. If there are no objections we'll use this window going forward and update https://www.drupal.org/documentation/version-info (which I think needs to happen for this to be marked fixed).

I updated the handbook: https://www.drupal.org/node/27362/revisions/view/9462479/9532683
Previously updated as well: https://www.drupal.org/node/2383987/revisions/view/9440949/9481889