In the ongoing efforts to build on lessons learned during the Drupal 7 cycle and fast-track Drupal 7 bug fixes, a new policy has been introduced to help ensure stability of the code base, based on recommendations by key members of the core contributor team, most notably Nathaniel "catch" Catchpole.

During my keynote at DrupalCon Chicago, I introduced a new "cap" of 15 on the number of critical bugs. If the number of critical bugs creeps higher than this, no new features or clean-up patches would be committed until the bug count went back down below the threshold. This would ensure that serious bugs are able to be addressed without having to "chase" the code base due other patches performing major under-the-hood refactoring.

However, it became clear that this was not sufficient. Despite heroic efforts on bringing the number of critical bugs to zero before launch, Drupal 7 still shipped with several hundred "major" bugs. While this situation has dramatically improved since launch, it is important to keep this number down, so that when Drupal 8 is released it is stable and ready to go. Additionally, sometimes bugs are fixed or features introduced that do not perform requisite refactoring of underlying systems, and we accumulate "technical debt". This technical debt makes the code base more complex and difficult to understand, and makes Drupal harder to approach for new developers.

Going forward, new features and other major refactoring patches will only be committed to Drupal 8 if the following conditions are met:

See also the Drupal core code freeze, code thaw, issue queue thresholds documentation page for more information. The "Contributor links" dashboard block on now also contains these counts for easy reference.

The hope is that this will allow us to strike a balance between innovation in the future Drupal release, and stability in the stable Drupal release of today, which will in turn help increase Drupal 7 adoption.


Thomas Svenson (not verified):

I am of course all for that fixing bugs in Drupal Core is very important. However, the more I learn about Drupal 7, the more I discover that unfinished features are going to be an equally big, if not bigger, problem to overcome.

Drupal 7 is a fantastic product and introduces so many new feature additions to form a great platform to build marvelous websites with. The problem, though, is that due to so many unfinished features site builders, developers and site administrators will have to spend a big portion of work on finding workarounds for them, or is some cases not be able to use the feature at all.

Especially the lack of using the hook_field_extra_fields(), to expose them on the Manage Fields tab, for several very often used User settings, including User picture upload and Signature setting (see, has become something of a pet project for me as reason for how important it is that uncompleted features can be completed in point releases.

Adding what is missing for this would not change any API's, only add a few new strings, but most importantly save a ton of unnecessary work and patch management for the majority of sites.

An even worse example is the Update Manager that has the ability to completely break sites in the state it is in now. If a contrib module has the same name as a core module, the chance is that the Update Manager will in fact update the core module, not the contrib. It will also happily downgrade modules if the contrib used is a dev version and there is an alpha, beta, RC or full release. The first is a bug, the second is both a bug and something that needs additional functionality.

Update Manager is also a perfect example of a core feature that should receive new features between major releases. It's purpose is to make it easier to update Drupal sites, nothing else. In fact, it should even be a goal to add functionality to be able to use it to update Drupal Core as well, even for Drupal 7.

I'm not advocating for introducing big new features in point releases, just that unfinished existing features are completed and polished.

I fail big time in understanding why this isn't more important for the community. After all, it would not only make Drupal so much better, and at the same time, without a doubt, save a lot of support issues and extra work needed to find workarounds.

In the end it wouldn't surprise me if it also would free up more resources for fixing bugs as well.

In many of the issues I have read, string freeze is often pointed to as reason for blocking a non bug fix patch. Why is this so untouchable? Doesn't every site builder face this issues with all the contribs anyways, most likely on a much larger scale?

I would be very happy if someone could explain this to me so it wont bother me so much anymore.