On the thread about a predictable release cycle for core, a large sub-thread opened up about the fact that everyone, including Dries, hates the way we do security vs. bug fix releases. It's confusing and unclear.
The current policy, explained
I couldn't actually find a handbook page explaining the current policy, so I made one. Here's a copy/paste of that here.
The current policy regarding release numbers is that if there's a security bug that needs to go out, two releases of the project will be created: one for just the security patches, and one for the security patches + all new bug fixes in the branch to date. This same mechanism is true of both Drupal core and contributed projects.
When we found security holes in Drupal 7.0, for example, we released Drupal 7.1 which had security fixes only, and Drupal 7.2 which included those fixes + all the bug fixes from initial release.
This approach is intended to allow site builders to upgrade immediately once a security hole is found, without the difficulty of wrangling patches, and without the terror of accidentally breaking their sites by pulling in upstream bug fixes that have not been widely tested yet.
Why people hate it
- Every time we do this, it looks like we made a mistake because the releases come out right after another.
- It's impossible to tell from looking at release numbers whether Drupal 7.5 is a security release or a bug fix release. You need to dig into the release notes to tell.
- It's really difficult to understand (even among the security team); advanced users would prefer patches.
Why the security team likes it
- The N, N+1 version numbering trick doesn't require any changes to various dependencies like Update Status/Update Manager, project packaging scripts, Drush, etc.
- The exact same process can be applied to both core and contrib, unlike slightly fancier methods "evens are stables, odds are security" that have been suggested.
- Patches are incredibly difficult for average site builders, who are the very people most likely to be harmed in an attack.
Possible approaches to solving this
- Allow "7.0.1" style releases
- Fix the packaging script to allow releases like "7.0-security" (needs to be checked with all the aforementioned dependencies)
- ...
So... FIGHT! (I kid ;))