After some 82 weeks of development beginning in February 2008, no one should be caught by surprise that we are in a code freeze for a release of Drupal 7, the next and best release of Drupal yet. However, as we all know, some of the best patches always happen at the last minute, and there are always last-minute patches that must happen. As part of my State of Drupal presentation at DrupalCon Paris last week, I talked about the Drupal 7 code freeze. Since not all of us could be in Paris, I wanted to share the relevant slides (PDF, 85 KB) in this post.

We're now in a phase we're calling "code slush", time boxed at a strict five weeks. In this period, most patches are allowed, except those that implement new features or functionality -- with some very important exceptions. Up to ten carefully selected exceptions for new functionality (see slides for details), patches that implement important and necessary API changes for existing functionality, and patches that improve usability, accessibility, documentation, and performance will still be accepted. As such, it is important that you start upgrading your contributed modules as soon as possible -- you never know what API issues you might run into and we only have a limited window to address those. After October 15, we will become a lot more strict and focus on the final polish.

As always, Drupal 7 will be ready when it's ready, but not before. We expect -- and hope -- that our huge investment in SimpleTest tests and our automated testing platform, though, will make this the easiest transition from development to release yet. We'll see!


webchick’s picture

  1. Image Field Heck yeah!
  2. Translatable fields Lookin' good!
  3. Convert Profile module to Field API Nope. :(
  4. Convert Taxonomy module to Field API Heck yeah!
  5. Admin overlays Very close!
  6. Edit anywhere Heck yeah!
  7. Customizable shortcut bar Heck yeah!
  8. Administrative dashboard Heck yeah!
  9. Plugin Manager (automated module updates) Heck yeah!
  10. RDF Heck yeah!

All issues at a glance:

Reminder that these are still time-boxed at Oct. 15 though. If they don't get in before then, it's D8+ for them. :( So as many people jamming on these as possible would be amazing!

webchick’s picture

There's been a movement called "#D7CX" started for module and theme developers to take a pledge to create to create full Drupal 7 releases by the date that Drupal 7 is released.

Read more about it here:

See a list of existing #D7CX projects:

And add yours to the list! :)

Note that right now would be an ideal time to at least start this process, since the APIs and markup in Drupal 7 are still malleable until code slush ends October 15. Coder module has a nice 7.x dev release to help! Here's a helpful video on how even non-developers can help port modules.

juan_g’s picture

webchick wrote:

There's been a movement called "#D7CX" started for module and theme developers to take a pledge to create to create full Drupal 7 releases by the date that Drupal 7 is released.

Yes, over hundred modules have already joined the D7CX movement (D7CX == "Drupal 7 Contrib Experience").

To facilitate timely module upgrades to Drupal 7.x, and to prevent the many months of delay that Drupal 6.x modules suffered (with essential modules being completely rewritten), in my opinion there should be some general guidelines, at least in the Updating your modules section.

For example, something like this (just a quick draft):

For a timely module upgrade, please make first just the upgrade. That is, only the necessary API changes without any new features, and without rewriting the module.

For instance, upgrade from 6.x-1.x to 7.x-1.x (or from 6.x-2.x to 7.x-2.x, depending on your current 6.x version). In this way -after a quick beta phase because of the lack of new features- your users have an almost immediate 7.x module release, with the same functionality of the 6.x version.

Developer modules like Coder and Schema can help you make the module upgrade. For Drupal 7.x, the Deadwood module is being merged into the Coder project and renamed to Coder Upgrade.

Finally, having already an initial, functional 7.x version, you can start a relaxed 7.x development, taking your time to add new features and improvements. For instance, slowly from 7.x-1.x to 7.x-2.x-dev, etc.
giorgio79’s picture

webchick’s picture

I've been compiling highlights of the major stuff that's happened in the release notes of the 7.x-dev release at

You can also see this in video and slide form at

I think that addresses all of the major questions people could have, so I'll quit spamming this poor post now. :D

suganyaM’s picture

The link lists the contributed modules that are moved to the drupal 7 core installation

Suganya M

irakli’s picture

Great news. Drupal 7 will undoubtedly raise the bar of excellence even higher!

Speaking of which, and looking at Drupal6/Drupal7 cycles: do you think core would benefit from introducing "maintenance-version" releases? Meaning, Drupal 6 was versioned using only major and minor versions, as: 6.1, 6.2, 6.3 ... 6.13 (the latest), whereas even a handful of security patches was causing the first number after the dot to increase. Considering that Drupal is becoming increasingly sophisticated, it may now be appropriate to reserve first number for feature improvements and use second dot for "maintenance" versioning? So the versions would be:

7.0 - Initial Release
7.0.1 - Maintenance: initial security patch
7.0.2 - Maintenance:: some other security patch
7.1.0 - a bunch of major performance improvements and some other significant changes
7.1.1 - Maintenance: minor security patch
7.1.2 - Maintenance: another minor security patch
7.1.3 - Maintenance: minor bug fix
7.2.0 - Some other major-enough update
7.2.1 - Maintenance: a patch
7.5 - "Sudden", non-sequential, "0.5" bump in the minor version signaling a major batch of _architectural_ improvements, possibly the ones that did not make it in before the Drupal7 freeze but caught-up over time.

Please note the sudden jump from 7.2 to 7.5. That's not technical and is quite important. "0.5" release is commonly used to signal an interim major release. So far we were only doing major jumps from say, 6 to 7 and major version change would signal that significant-enough architectural changes are made that core team may not provide backwards-compatibility. But as the time period between major releases inevitably grows, significance of an interim "almost major" release, that may not break compatibility but may be big enough to cause paradigm shift in how things are done could be very helpful. An example of such thing may be - new plugin manager? Such approach could decrease drama surrounding a major-version freeze, by introducing an interim "almost major" release.

Just a thought.

Thank you

sepeck’s picture

We had what some complained was a more complex version numbering system at one time that resulted in complaints. So we switched to the current method and the complaints/confusion went away.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

LUTi’s picture

I've suggested a 3-level (7.0.1 kind of) versioning quite some time ago... ;-)

It is very common in linux world, where people are more logical and humble. You can see just the minor version number to grow for years, altough there are improvements all the time, and the woftware works very stable...

In windows, you can often see versions growing very fast (a new major number even every few months...), altough every new version brings only some more (new) bugs and inconsistency in behaviour (features)...

Not to mention that I 100% agree with irakli. It would make my life easier, if I know from version number already if I have to expect some different behaviour (new features) and read documents more carefully, or there are "just some bugs fixed" (and, everything shall after the upgrade work more or less as before...).

Would it really be so complicated to understand that version 6.2.0 is newer than 6.1.11?! How all those people handle the logic that 6.11 is newer ("more", if we say the versions or version numbers are growing...) than 6.2, altough with numbers 6.2 (= 6.20) is more than 6.11?! ;-)

sepeck’s picture

We used the Linux kernel release version method for years. It resulted in much hue and cry and gnashing of teeth that eventually we switched to the current method. There is a rather complex CVS/Project package and release system that had to be rewritten to accommodate the changes to the version number system as well. It is not something done lightly or on a whim so is not likely to be revisited until several other major community projects are completed.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

ScoutBaker’s picture

I agree.

And what the others seem to be missing is that new features are only added to new versions in the current versioning system. So their confusion is of their own making. You won't see, for example, fields in core being backported to D6. It's being added to D7. New features = new version. Simple enough.

irakli’s picture


I think the problem you are referring to was in regards of versioning for contributed modules? I wholeheartedly agree: there's no need to change those - vast majority of modules are simple and straightforward enough that they, indeed, would suffer from any further sophistication. When I was talking about 3-level versioning, I meant only core. Sorry if I was not clear about that.

Drupal core has grown a lot in the past several years. It is much more complex, used in many more ways than before, and by a far larger community. Considering these developments, and acknowledging that software is a living-breathing "creature", I think we should be open to, at least the idea, of a possible change as far as core is concerned.

In my eyes, more sophisticated/robust versioning system for core is tightly related to the movement towards #smallcore. Obviously, the idea of small core is not just the size (actually, that's the least concern) but main point is decoupling of concerns and making core more dynamic. More dynamic core will require more robust versioning as well. I think the two go hand-in-hand.

sepeck’s picture

I understood what you meant and no I was not referring to contributed module versions. It is far more complicated in terms of user education, infrastructure modifications and resources to change it. I, also, do not see the current practice of freezing version api's changing in the next few years either so yet another reason not to worry about it.

This is also not the place to continue this discussion.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

fletchgqc’s picture

I'm impartial to this, but I do suggest that "current scheme using double-digit decimals" would be better than the current scheme. That is: 7.01, 7.02, 7.03.... instead of 7.1, 7.2, 7.3.

Only because you eventually get to 7.10 and then.... Which is the newer version, 7.12 or 7.2? I found the answer 7.12 slightly confusing when I first came to Drupal.

seutje’s picture

current versioning makes a lot more sense to me, 7.5 is preceded by 7.4 which is preceded by 7.3 ...

also, I believe we need the drama surrounding code freeze, it makes a lot of people get off their ass and get hacking

no pressure === no advance

batsonjay’s picture

There are several justifications why this makes sense.

1) The user community has grown, and a larger number of site admins will be accustomed to this approach. It's a fairly common use case in the software world. It's arguable that objections to this more complex numbering were taken from a smaller sample of people (early in Drupal days) who didn't represent a sufficiently large number of people running production application environments. If you ask the same question today - NOT only among developers, but among people running operational environments - this would be perfectly acceptable.

2) Drupal major release cycles are long, and it takes too long to get something into "official" Drupal. Drupal is moving mainstream; to have to wait two years to see significant things get into Core is too long for companies (Sony, etc.) to wait. Key core performance improvements need to move at web speed. Major releases should still take a long time; but there should be a mechanism for "important new features in core" that happens at a faster speed.

There are certainly operational issues with having this approach, too. Does that change core maintainer time commitments (to an unacceptable level)? Is this too hard to manage within CVS?

I'm no Dries; I'll admit it. And I don't speak for him. But if I were thinking like a product manager in a software company, I'd be looking at a 3-level release system.

Nonetheless, the approach is sound IMHO.

seutje’s picture

biggest problem with that is contrib, cause not only will they have to change from a 7.x-1.0 naming to a naming but it will also result in the D6 problem every time

without a proper codefreeze it's impossible for contrib modules to be up-to-date the day it gets released, resulting in a lot of people not updating till their used contrib modules are updated

I agree that this might make sense for traditional projects, but they don't rely so much on a strong contrib repository, and sudden API changes without a real warning will cause the panic and the screaming and the "aaargh"

rickvug’s picture

I agree that API changes should not be made within the 7.x life cycle. However, I think that reserving the right for a 7.1.x (or whatever) release with feature/usability enhancements would be wise. For example, there may be interface or usability improvements from Drupal 8 development that can be backported to Drupal 7 without changing existing APIs. I think this would be a wise decision considering the length of Drupal's release cycles. It is also additional motivation for developers as they'd would not have to wait as long for their improvements to be usable in the real world.

Rick Vugteveen | @rickvug on Twitter

espie’s picture

I believe you're asking the wrong question. What's the point of a 3 numbers release scheme ? avoid testing new features ?

The thing in drupal7 that excites me the most if the new test framework. I hope people spend a bigger fraction of their time
running tests, and less thinking about numbering schemes.

A thing about version numberings: most complaints go away when it's a strictly upward path. Introduce no regressions, and
people will update naturally.

Who cares about the actual numbers ? I only want it to work better and better...

hawkdrupal’s picture

+1 for more informative and standard release numbering. Why not? Will one more dot confuse the amateurs?

A related practice is how modules are numbered. The "x" as in 7.x is silly, since it seems to never change to anything else, so why include it?
And the use of -dev to identify a version is really a pain. It's dangerous that there are sometimes many -dev versions with identical file names, distinguishable only by their release dates. ALL key info should be in the release/file name, not requiring an additional external (or internal) reference.

Again there are many proven practices for this, including using a 4th dot position to indicate experimental "dev" iterations that are at the testing/beta level.

For example, using the same naming convention proposed for Drupal itself, using a module named "Module":

Module- -- initial release
Module- -- first code tweak that some might want to try per a discussion, but not a "supported" or fully-tested update
Module- -- another code tweak that some might want to try, but not "supported" either
Module- -- supported minor update
Module- -- supported major update

I've seen the 4th position do into 2 or 3 digits at times, and why shouldn't it? The goal is precise clarity, after all...

(A variation on the 4th position is to use a date-time instead, such as or 7.0.1-20090923, which is more precise but a tad longer than incrementing numbers. And it doesn't make clear what version precedes or follows it.)

The ultimate goal is to make file names as self-identifying as possible (and always unique) -- making development and admin management more stable and life easier all around.

chx’s picture

I ran over this topic and everyone suggesting a new versioning scheme is not a name familiar from the core queue. Do first, talk later. No, you do not need to know how to code.

Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

jpetso’s picture

Before suggesting a three-numbers versioning approach, it makes sense to take a look at *why* the majority of Free Software uses that kind of versioning, and why it made sense for Drupal to switch away from x.y.z (up to 4.7.x) and adopt x.y (since 5.x) instead.

Most Free Software that uses x.y.z does so because they distinguish between feature releases ("y" part) and API/ABI-breaking releases ("x" part). If I use any of its API in version 4.0.z, my application (or module, if we stick to Drupal terminology) will work without changes on version 4.1.z, in 4.2.z, and all later versions of 4.y.z. When the base software is updated to 5.0.0, my application is very likely not to work anymore, and I need to port it to the new API.

That is the sole technical reason for this kind of versioning. When there is no notion of API/ABI compatibility, the three-level numbering scheme is nothing but marketing babble, which might work fine for some few projects like Firefox but has little value in itself. Most importantly, three-level numbering without a change of the development model itself is not helpful to anyone, as it's hard to draw a line between the difference of 4.7.z going to 4.8.0 or to 5.0.0. The lack of a quantifiable measure (API/ABI break) keeps the end user in the dark about the exact rationale for the chosen version number, and requires the developer(s) to judge the scale of the improvement over and over again for no good reason. Drupal did the right thing by adapting its versioning scheme to the way that Drupal development actually works.

Whoever says x.y.z must also say "feature releases without API changes". And require Drupal core to keep even the most unimportant of its publicly exposed APIs source-compatible (the ones that don't start with an underscore), in all of the modules shipped with core. I don't say this is a bad idea, and Drupal might decide to back away from its "feature releases always come with API changes" stance at some point. Or it might not, because its public API is not designed to remain stable. Either way, one should not be talking about version numbers but rather about the merits and downfalls of retaining API compatibility. Not that it hasn't been discussed to death on the development list multiple times already.

hawkdrupal’s picture

One of the original pleas in this thread was that Drupal could find more open doors in major businesses if Drupal presents itself more like what IT pros get from other companies -- IBM, Oracle, Sun, etc. (Not everything about Free Software needs to be different just to be different. It's not a religion or club, it's a business method.)

Jpetso provides a good explanation of one of the ways to provide key information via 3-section versioning. Please note that there are other common schemas too -- the notion of versioning goes back many, many years and is applied in different ways. But regardless of specific semantics, what 3-section versioning (or 2-section or 4- or any scheme) MUST do is provide absolute identification of each version/file, including minor variations.

This need applies to ALL of Drupal, notably the contributed modules that make it so powerful and useful. But with outside modules there's little numbering consistency and even less "meaning" to the version numbers.

The common use of "dev" in Drupal module names for ongoing tweaks/changes is simply a disaster. I suspect it originally was a simple way to identify experimentation by the developer for those who wanted to help or test. But with many modules that's not what's really happening.

In several modules I track (because I used them or are considering them), there are sometimes months and months of "dev" releases that actually the CURRENT version to be using. Wander around Issues and Discussion pages and look for "make sure you're using the latest dev version" or similar statement. So why is it called "dev"?

Many times I've downloaded a "dev" version based on such advice, only to have my PC complain that the file name already exists -- because I grabbed a different "dev" of the same module some time back. Sure, I can and do rename the files to keep them straight, but under what circumstance should there be two versions with the same name? Who does this help, vs. potentially hurt/harm/screw up? And how can any of us communicate about which version does what if we are making up our own file names?

Considering naming methods, what does a module name like this mean: coolmod-5.x-1.x-dev ? Why does it take further discussion/readme or whatever to explain how this "dev" is different from the prior "dev" and later "dev". This defeats any attempt to systemize application maintenance and updating.

Why not step the names to coolmod-5.x-1.0 then coolmod-5.x-1.1, then coolmod-5.x-1.2, etc?

OK, maybe 1.0 to 1.1 is too big a step, as implied by "dev" which probably indicates minor interim changes, bug fixes, etc. So why not use 3-section numbering: coolmod-5.x-1.0.0, coolmod-5.x-1.0.1, coolmod-5.x-1.0.2, and eventually if justified, coolmod-5.x-1.2.0 ? Isn't incrementing the third number position much better than reusing "dev" over and over?

Michelle’s picture

The "dev" version isn't really a version. It's an automatically generated snapshot that is created every 12 hours if there are changes in the code. Whether or not this snapshot is usable varies from project to project and sometimes even day to day within a project. If a maintainer is telling you to use a dev snapshot, and it's not a temporary situation, then they're doing it wrong. Yes, it happens on far too many projects. But that doesn't mean there's something wrong with the release numbers; it means the maintainers aren't making releases like they should.


rickvug’s picture

@jpetso I agree with all of your post. I think you are overlooking one option however: introducing improvements does not necessarily mean changing APIs. What if a Drupal 7.1 update was a collection of usability improvements and simple features backported from Drupal 8 (HEAD) development? This would allow for improvements to come to market quicker (increasing developer's incentive to contribute) while saving all major changes to Drupal 8, which would have a longer development cycle. Contrib modules developed for Drupal 7.0 would still work with 7.0.1, 7.1, 7.1.1, 7.2 etc. with no changes.

Rick Vugteveen | @rickvug on Twitter

Direct’s picture

How did u do such a great presentation in pdf?

jpetso’s picture

Assuming Dries didn't change his habits recently, he's using Apple Keynote for creating his presentations. As with pretty much every office suite in existence, you can export the slides from the presentation editor to PDF, and voilà, you've got a portable document file for everyone to view in their preferred PDF viewer (i.e. Okular).

mradcliffe’s picture

I'm not sure I understand. We're code frozen now, BUT you're still reviewing all the patches? Don't some of the 271 patches that need review still contain new features? Will those issues that have needed review since before Drupalcon be disappointingly delayed until Drupal 8? I'm hoping that we can finally officially disable RSS without a contrib hack.

This is kind of confusing.

robertDouglass’s picture

It means that any patch can get in that deals with bugs, usability, performance, etc. Patches that introduce features have to fall into one of the 10 exception categories. These 10 exception categories go away Oct. 15th and then it's just polish until release. It's all there - read the post carefully, and if there are still doubts, you can watch Dries' keynote on the internet archive. It's a nice transition into a code freeze.

my Drupal book | Twitter | Director, Product Operations Commerce Guys

dodorama’s picture

Thanks for posting this.
Is there any plan to make this the standard development cycle?

sepeck’s picture

This is pretty much what has been done each cycle for several years now. Admittedly there are more issues in the 'slush' pile then usual. Not 'formalizing' it leaves much flexibility.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

dodorama’s picture

It makes sense.

j0rd’s picture

I'm looking forward to learning and moving my development cycle onto Drupal 7. Hopefully the usability improvements will make Drupal more intuitive for my clients.

Coupon Code Swap’s picture

Would it be relatively safe to begin developing a new website using Drupal 7 now that the code freeze is in place? The site wouldn't require any low level hacks and would only need a couple additional modules i.e. CCK and Views to get started.

Chomping at the bit to get going and check out the shiny new Drupal :)

Michelle’s picture

The Drupal 7 release could still be 6+ months away. And Views hasn't been ported, yet.

I wouldn't start building a site on it until at least beta and we haven't hit alpha yet.


Coupon Code Swap’s picture

So then, probably better to get started with Drupal 6 and hope for a smooth upgrade.

chrisbeaman’s picture

Excited for Drupal 7!

websule-old’s picture

Congrts to All the developers who have been working hard day n nights to get Drupal to this point.
After Drupal 7 Code Freeze , We all now look forward towards the official release of Drupal 7.

Samuel Lavoie’s picture

That's a really long development, in fact this get me thinking about proprietary "big" solutions... but hey it's OO and free so Drupal should be both rock solid et full features... and with this kind of community nothing can beat it, isn't it? ^_^

cosmicdreams’s picture

I recently attempted to install DRUPAL-7-0-UNSTABLE-9 and ran into a few problems during the install. All my problems went away after I upgraded my LAMP stack and started completely from scratch. I was surprised how much things have changed. Pleasantly surprised.

I love the new administrative theme, Seven. Items seem to have a natural, logical order to them. I can't wait to see performance comparisons of Drupal 6 and 7 because I'm seeing a tangible speed improvement of navigating between administrative pages. These days pulling the modules page up in a Drupal 6 install can be unnaturally long.

I'm hoping I will have a good chunk of time available to help squash bugs and test patches before December. Keep up the good work gang!

alesr’s picture

Where is Drupal 7?

Michelle’s picture

WorldFallz’s picture

No need to clog the forums asking the same question multiple times-- I've deleted the dupe, thanks.

Care about the future of the forums? Please join our conversation and show support for improving the forums infrastructure.

alesr’s picture

I thought that D7 stable is launching on December 1st.

Sorry for double posting.

Michelle’s picture

Maybe sometime next Spring. We just had the UX freeze on Dec 1. We aren't even to Alpha, yet.