Proposal: Do core security releases on different dates than bugfix releases

The following proposal grew out of some ideas I've been thinking about recently, with input and refinement from members of the Drupal security team. I am putting it up for public discussion and hope to implement it as soon as possible.

The proposal is simply to stagger security and bugfix point releases of Drupal core, so that we no longer aim to do both on one day. The content of the releases would remain the same.

To be more specific, I am proposing that we have two Drupal core "release windows" per month, as follows:

1. Bugfix releases on the first Wednesday of the month. (Next release window: November 7)
2. Security releases on the third Wednesday of the month. (Next release window: October 17, assuming we implement this policy in time. The one after that would be November 21.)

This can be compared to the current policy, in which security releases come out with a corresponding bugfix release on the exact same day (nominally the last Wednesday of the month, although recent history shows that in practice it has been the first Wednesday for a while).

The reasons for the proposed change are:

1. To reduce confusion inherent in having two releases on the same day.
2. To make the lives of release managers (like me!) easier, so that we don't have to plan and coordinate two releases at once just because there's a security problem that needs to be fixed. Instead, security releases and bugfix releases will go out independently, only when they are ready.
3. To allow the Drupal security team to develop fixes against a stable point release of Drupal core, rather than against two versions at the same time.

In discussing this proposal, it is important to emphasize several points:

1. As with the current policy, the above dates will only be release windows; there is no guarantee of an actual release on any of these days. For example, Drupal 7 is relatively stable and has lately been getting bugfix releases only every three months or so (a pattern I expect to continue). Core security releases, meanwhile, happen in whichever months they need to, but in practice do not occur every month either. However, we still want to have the windows every month in case we need it.
2. Even though they will be on separate days, the releases will contain the same content they do now (the security release will contain only security fixes on top of the previous Drupal core point release, while bugfix releases will contain all fixes). As a concrete example:
   • Drupal 7.15 is our most recent release. It came out on August 1.
   • Let's assume we do make a security release (Drupal 7.16) on the October 17 release date. This release will only contain security fixes on top of the Drupal 7.15 codebase. Other patches which were committed to 7.x-dev between August 1 and October 17 will not be included.
   • Let's further assume we go ahead with a bugfix release (Drupal 7.17) on the November 7 release date. This release will contain all bugfixes committed to Drupal 7.x-dev between August 1 and October 17, the security fixes from Drupal 7.16, and additional bugfixes committed to Drupal 7.x-dev after October 17, all in one package.

   Although the security fixes which were developed for Drupal 7.16 will be committed to 7.x-dev as soon as the hypothetical Drupal 7.16 release happens, we might need to discuss them further (in the public issue queue) to make sure they are fully compatible with the latest 7.x-dev code, before the next stable bugfix release of Drupal core can happen. The effect of this is simply to offload some work that would otherwise have been the responsibility of the security team alone, but really does not need to be.

3. Finally, the specific identification of the "release windows" with the first and third Wednesdays of the month is a goal, but always subject to change based on various factors that might conflict with it (holidays, personal schedules, etc.) We can try to announce in advance when a particular release window won't be on the expected date. And of course, in the event that a highly critical Drupal core security release is required (for example, due to a vulnerability being actively exploited in the wild), the designated release window may be ignored then also.

I hope this proposal seems reasonable and that it continues the progress towards a simple, predictable, and easy-to-understand release procedure for Drupal core which Angela Byron (webchick) began working on last year.

Please feel free to leave any comments on this proposal below. Thanks!