Policy: Change advisory release window day to Tuesday

It seems to me that the tension is between the team preparing the releases and those who have to operate on them. I'm guessing that Wednesday was picked to give both groups equal time. Moreover, I'm also guessing (i.e. I don't know) that the Security Team wants to release as early as possible on Wednesday.

Since I never release on Friday (as tguilpain mentions), for me and other teams with Thursday releases the available time really is just:

• North America: perhaps a few hours on Wednesday and all day Thursday
• Europe: All day Thursday

Thus, the three ways forward I see are:

1. Keep as is
2. Rigorously release early Wednesday mornings Eastern Standard time (i.e. 9am EST) thereby giving at least teams in NA reliable hours Wednesday afternoon (doesn't really help Europe much); this gives the Security Team time to prepare during the week
3. Monday releases; great for Europe; DST has to finish all its work the prior week; bad when there are long weekends that take place on Mondays
4. Tuesday releases; some sort of middle ground and avoids the long weekend problem to some degree

It looks to me that 2 and 4 are possibilities but this really needs DST members to chime in. I imagine that Wednesday might also have been picked so that there was Tuesday to prepare for the Wednesday release when there are long weekends.

And then there is Asia :-).

(I'm a consumer in North America and can make any of the above work.)

"Timezones, man!"

I'd like to refine this proposal slightly.

A few things stand out about this topic:

0. Due to the fact we don't all live on a flat earth, that we're on a planet that's rotating as it spins around the sun, we have timezones as a limitation we have to deal with. This unfortunately means that portions of the Drupal community are going to loose out as regards to when the releases are made. Given that the majority of Drupal sites are in the US, and the majority of members of the DST are in the US, we focus on US timezones.
1. We want to give people as much time to be able to complete the necessary regression testing and UAT prior to launch as they can, so people East of the US generally have to deal with the releases on their Thursday, instead of Wednesday like in the US.
2. The security team and project maintainers need time in order to complete their releases.
3. Due to the current AI firehose effect, the DST has been refining internal processes.
4. It is fairly common during the year for Mondays to be a holiday in different countries, it is far less common for Tuesday to be a holiday.
5. In a world of thousands of contrib modules and ~40 weeks during the year where contrib projects can be given a security release, it wouldn't be a terrible problem to postpone a release a single week.

I would like to propose the following:

1. Except in emergencies, the list of projects being released in a given week be finalized by EOD (Eastern US time) on the Friday before the release window; if a release isn't ready to go by the Friday then it gets pushed to the following release window.
2. The release window is moved from Wednesday to Tuesday.
3. We try to publish SAs as close to noon Eastern US time as possible; we already do try to, but adhering to item #1 might make it easier.
4. We could separately consider publishing them earlier, but I think this is a discussion worth separating from a decision on which day the releases happen on.

We could split this out into separate proposals to let this issue focus exclusively on the release day while the other ideas are pushed to other issues?

Plus 1 to the proposal, being in indian timezone, we generally get to know exactly on thursday about what's the actual impact, which gives very little time in the week to do production hotfixes, having the releases on Tuesday will be very much helpful.

+1 for moving the window to Tuesday (or Monday).

As a Project Manager, Wednesday releases place significant pressure on scheduling. In European/Asian timezones, advisories drop late Wednesday, leaving effectively only Thursday to review the advisory, apply the patch, run UAT, and deploy.

Because we enforce a strict "No Deployments on Friday" policy to safeguard our team's weekends, any patch that cannot be fully vetted on Thursday gets pushed to the following week. This extends our exposure window unnecessarily.

Having the release window on Tuesday would give teams a realistic 2-day runway (Wednesday and Thursday) to properly test and ship security releases safely before the weekend.

On the topic of time zones, it may be worth noting how they line up.

6am PST, 9am EST, 2pm UTC, 3pm CET, 7:30pm IST, 1am AEDT
9am PST, 12pm EST, 5pm UTC, 6pm CET, 10:30pm IST, 4am AEDT
12pm PST, 4pm EST, 9pm UTC, 10pm CET, 2:30am IST, 8am AEDT

IMHO, the current 12 pm EST suits the fewest regions in terms of office hours.
https://www.worldtimebuddy.com/?qm=1&lid=8,5,100,14,12,30,21&h=100&sln=1...

I'd like to propose to change the scheduling of the security release windows too, as following

Contrib projects - Every 2 weeks
Core - Once per month

In order not to overlap, given a month has 4 weeks, core can be on 3rd week, as it is already, and contrib on 2nd and 4th.

This process as a great impact already to everyone involved, especially for the sec team which I can't imagine the levels. If this proposal increases the workload and stress of the sec team, I understand not going with this.
For the agencies, developers etc, having some sort of break and allowing more time to apply the security releases to their projects, can make it less stressful. I wouldn't mind updating 3-4 modules more every 2 weeks

I think the day, frequency and time discussions should be separate to make this easier to discuss.

It's unrealistic to reduce the frequency of contrib releases when the current volume is so high, it would mean having to release potentially more than 100 SAs on a single day. Regardless of how much preparation is done in advance, that would be unsustainable to do during a single window - unless we extend the window to the entire day or something but then there is effectively no defined window. Agreed with #9 that the discussion should be split.

I'm mostly ambivalent/slightly against the proposal if only that it means that plannings and schedules that have now worked for years need to be uprooted.

The reason for the request ("it takes us a long time to deploy a security release") worries me though. With the advent of AI I do not think it's realistic to think that attackers are going to wait for internal business processes and approvals before they decide to start attacking with information from a published security release.

Perhaps it warrants a separate issue, because I don't want to derail this conversation, but I'm very curious what is preventing companies that use Drupal from rolling out security updates in hours rather than days? I realize a large part of it might be bureaucracy, but I think the "time to exploit" in the current world is rapidly going from "days/weeks" to "hours" regardless of the severity of the vulnerability. In the near future, being able to react to vulnerabilities within an hourly time-frame will become table-stakes for companies.

Rather than spending energy moving the release window by a day to support an arguably broken process, I'd love to see that energy invested instead in enabling Drupal teams to roll out security fixes more quickly. It could be a huge selling point for Drupal and any organization using it if we can ensure that everyone is able to respond to security releases quickly and safely using automation.

Perhaps it warrants a separate issue, because I don't want to derail this conversation, but I'm very curious what is preventing companies that use Drupal from rolling out security updates in hours rather than days?

Remember that the size of Drupal companies and the number of websites they manage varies a lot, from large teams managing a single platform to small agencies with dozens of clients.
The level of automation (CI/CD) probably also varies a lot.

As a small company that manages more 50 websites the proposed change would definitely give us room to breath. Even with automation it is hard to fit updating every website in a single work day.

I realize a large part of it might be bureaucracy, but I think the "time to exploit" in the current world is rapidly going from "days/weeks" to "hours" regardless of the severity of the vulnerability.

This is not really the case for a lot of core SAs though. We release SAs for a lot of things that are only exploitable with a specific contrib module installed, or only exploitable if someone is able to create/edit content on the site etc. when many sites don't have open registration or permissions to create content for untrusted users, they may only have one user in total.

This means that a site may well know that they're not vulnerable as such, and want to release the security release as part of a general deployment window, but also that they might not want to do that the week after the SA comes out.

Taking 'frequency' out of the title here, if people want to discuss the time of day and frequency of release windows, please open separate discussions and link them from here.

(shortening the issue title)

Sometimes security fixes remove mis-features or cause unavoidable BC breaks, especially in contrib. See the Entity API module for example. A security fix removed JSON:API access that wasn't supposed to be exposed. Anyone depending on that bad behavior suddenly had broken sites. The fix to restore it belonged to whatever module implemented the entity but not the Entity API module itself.

I'd also support moving to Tuesday for reasons such as that, even though I am under no time pressure.

I recommend moving the release window to Tuesday (or Monday).

From a project management standpoint, the current Wednesday schedule creates severe operational bottlenecks for distributed teams. When advisories drop late Wednesday in European and Asian timezones, Wednesday is effectively lost. This leaves Thursday as the sole working day to review the advisory, apply the patch, run UAT, and deploy.

The current 12:00 PM EST release window suits the fewest regions during active business hours.

Because the current slot hits at the end of the workday in Europe, late night in India, and the early morning hours in APAC, immediate remediation simply cannot happen during normal shift hours.

Compounding this, many organizations including ours enforce a strict "No Deployments on Friday" policy to safeguard production stability and team weekends. If a patch cannot be comprehensively tested and cleared during Thursday's narrow window, it gets deferred to the following week. This rolls our exposure window over the weekend for an unnecessary extra 3 to 4 days.

Shifting the release to Tuesday (and ideally targeting an earlier slot like 9:00 AM EST) provides a realistic two-day runway across Wednesday and Thursday. That gives global teams the space to thoroughly vet, test, and ship security updates safely without forcing late-night scrambles or extending vulnerability windows over the weekend.

+1 for Tuesday (or monday).
On #11: we automate as much as we can, but as an agency running many client sites, part of the delay is client-side validation we don't control. Having Wednesday and Thursday instead of just Thursday makes a real difference there.

+1 for Tuesday.

+1 for Tuesday or Monday too

+1 for Tuesday too

I think it has been established that this would be useful for some companies.
Commenting +1 now just adds noise.

+1 for Tuesday too

We have a lot of people in agreement with changing the day to Tuesday. Is there anyone who believes it should stay as-is on Wednesday?

There were significant conerns from Security Team members of whether this would allow enough time to get releases prepped.

I think we should wait a bit longer for those thoughts to percolate and evolve before making any kind of decision, and work on other areas of process improvement before considering this change.

For me the main barrier to moving this to Tuesday, is that there are often public holidays on Mondays.

So for core, I would want two usable windows per month, so that there when there is a public holiday just before a window, we can definitely use the other window without having to release a PSA for an off-schedule security release.

This would help if we need to e.g. do a co-ordinated release with an upstream dependency too.

Then contrib releases could continue to happen on core windows that aren't used by core (or possibly alongside core releases but we usually avoid that to simplify things for site owners).

There were significant concerns from Security Team members of whether this would allow enough time to get releases prepped.

I think that other policy adjustments should be taken into consideration to make handling this easier, but those are separate topics.

(a key proposal would be to have everything ready the Friday before the release, so that we (DST and project maintainers) know the week before whether something is going out, rather than often deciding the literal day before or even morning of release)

We're not opposed to the proposal, I think for our situation it would actually be a better fit than the existing window. I just wanted to mention that due to the fact that both the existing and the proposed window will be outside our regular office hours, for us it would be important that any change would be communicated well in advance. It won't be a problem to adapt our processes, but at least in some cases people might have to reschedule long-term private commitments so that they can be on stand-by. For some, it would also affect the schedules of family members. So an announcement at least a few months in advance would be appreciated.

So an announcement at least a few months in advance would be appreciated.

Absolutely.

Yes, I added some to the implementation plan to cover this would be communicated well in advance of any change.