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

David_Rothstein's picture

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!

Comments

+1 from me. Hopefully this

greggles's picture

+1 from me. Hopefully this makes the process simpler for all involved.

Makes sense

Crell's picture

This makes sense to me, and makes life easier for maintainers. I like.

+1 This is great

Fabianx's picture

+1 I like this. This really would help.

Isn't the purpose of

Jorrit's picture

Isn't the purpose of security updates that they are released whenever needed? I find it strange that security releases are "planned".

In recent years, at least,

David_Rothstein's picture

In recent years, at least, security releases have generally been done this way (on a planned, pre-announced date). This proposal would not change that.

The reason for doing it that way is that it's good to give site administrators some notice of the release window so that they can plan to be available on that day to actually update their sites, in the event that a security release is made.

As mentioned, in the case of an urgently-needed security update (highly critical, being actively exploited in the wild, etc.) we can still break the pattern and release whenever is necessary.

Would be great, if there will

renat's picture

Would be great, if there will be a specific page to find out, are there any plans to roll out new core version at particular release window. I think, it's more or less clear in advance. This data will simplify planning for a Drupal webmasters.

I plan to continue doing

David_Rothstein's picture

I plan to continue doing short blog posts to Drupal Planet (example) a couple days in advance of bugfix releases, so people can look for those to see if an actual release is coming soon.

For security releases, I could do the same thing for the release window (but we won't necessarily know or make public in advance whether or not an actual security release is going to happen that month).

I like the idea of additionally documenting the status on a central page somewhere... but not sure where. Maybe just on the project page (http://drupal.org/project/drupal) itself?

I think it would be nice to

renat's picture

I think it would be nice to have a blog posts in case it is clear that there will be no new release in a particular release window as well. If there is no message, it is not 100% guarantee there are no plans for release.
Drupal Planet is a good place for such messages, but as well it could be special group for releases announcement only here, at GDO.

I'm not sure, should we post some information about it at Drupal project page. I don't think it is so useful for a new or occasional developers. It is useful for people, who spend much time working with Drupal, especially in case there are much Drupal sites they're accountable for. And Google indexes GDO fast, so there will be no problem to find message about upcoming version, assuming such message is actually there.

1 from me.

TheodorosPloumis's picture
  • 1 from me.

Drupal 7, Drupal 6, Drupal anyway...

Implemented!

David_Rothstein's picture

Thanks for your comments, everyone.

It sounds like people are in favor, so we're going to go ahead and try it and see how it goes:

I couldn't think of anywhere else that needed updating, but if someone can, please let me know.

For now, we'll just continue to do the release window and release announcements via this group (and therefore via Drupal Planet), as discussed above.

If anyone has any further comments about this policy (especially as it begins to go into effect), feel free to continue the discussion here.