Drupal 7 code freeze

By Dries on 15 Sep 2009 at 21:12 UTC

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!

Comments

Exception list

webchick

she/they

English

Vancouver 🇨🇦

commented 15 September 2009 at 21:26

~~Image Field~~ Heck yeah!
~~Translatable fields~~ Lookin' good!
~~Convert Profile module to Field API~~ Nope. :(
~~Convert Taxonomy module to Field API~~ Heck yeah!
Admin overlays Very close!
~~Edit anywhere~~ Heck yeah!
~~Customizable shortcut bar~~ Heck yeah!
~~Administrative dashboard~~ Heck yeah!
~~Plugin Manager (automated module updates)~~ Heck yeah!
~~RDF~~ Heck yeah!

All issues at a glance: http://drupal.org/project/issues/search/drupal?issue_tags=Exception+code...

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!

Contributed module and theme authors..

webchick

she/they

English

Vancouver 🇨🇦

commented 15 September 2009 at 21:36

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: http://cyrve.com/d7cx

See a list of existing #D7CX projects:
http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&di...
http://drupal.org/project/themes?solrsort=sort_title%20asc&text=d7cx&dis...

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.

Guidelines for timely module upgrades?

juan_g commented 16 September 2009 at 09:07

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.

Upgrade smart!

giorgio79 commented 16 September 2009 at 20:14

Upgrade smart! :)

http://drupal.org/project/deadwood

My Drupal sites:

Other places to help out...

webchick

she/they

English

Vancouver 🇨🇦

commented 15 September 2009 at 21:45

"What's new in Drupal 7"?

webchick

she/they

English

Vancouver 🇨🇦

commented 15 September 2009 at 21:48

I've been compiling highlights of the major stuff that's happened in the release notes of the 7.x-dev release at http://drupal.org/node/156281.

You can also see this in video and slide form at http://webchick.net/node/70.

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

Drupal 6 contributed modules moved to drupal 7 core

suganyaM commented 15 September 2010 at 12:34

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

http://drupal.org/node/895314

regards,
Suganya M
http://suganya-drupal.blogspot.com

Introduce "Patch Release" Versioning?

irakli commented 16 September 2009 at 02:54

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 commented 16 September 2009 at 03:04

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}

I've suggested a 3-level

LUTi commented 18 September 2009 at 14:06

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?! ;-)

yes it would

sepeck commented 18 September 2009 at 15:02

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}

I agree.

ScoutBaker commented 18 September 2009 at 17:59

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.

Software grows and matures

irakli commented 22 September 2009 at 03:43

Sepeck,

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 commented 22 September 2009 at 16:07

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}

Current with double-digit decimal

fletchgqc commented 17 October 2009 at 13:53

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.

current versioning makes a

seutje commented 16 September 2009 at 05:21

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

+1; admin's can deal with this.

batsonjay

Boston, MA

commented 17 September 2009 at 00:06

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.

biggest problem with that is

seutje commented 17 September 2009 at 05:18

biggest problem with that is contrib, cause not only will they have to change from a 7.x-1.0 naming to a 7.5.1.0 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"

I agree (but...)

rickvug commented 17 September 2009 at 06:11

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.com @rickvug on Twitter

I believe you're asking the

espie commented 19 September 2009 at 18:29

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...

Why NOT bring Drupal versioning into software mainstream?

hawkdrupal commented 23 September 2009 at 16:17

+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-7.0.0.0.tar.gz -- initial release
Module-7.0.0.1.tar.gz -- first code tweak that some might want to try per a discussion, but not a "supported" or fully-tested update
Module-7.0.0.2.tar.gz -- another code tweak that some might want to try, but not "supported" either
Module-7.0.1.0.tar.gz -- supported minor update
Module-7.1.0.0.tar.gz -- 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 7.0.1.20090923 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.

Why here

chx commented 24 September 2009 at 02:04

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.

Purpose of "patch release" versioning

jpetso commented 27 September 2009 at 06:27

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.

Why are modules so often numbered "dev"?

hawkdrupal commented 1 October 2009 at 02:10

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?

No, not better

Michelle

she/her

English

Wisconsin, USA

commented 1 October 2009 at 03:13

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.

Michelle

Improvements don't always need to break APIs

rickvug commented 1 October 2009 at 08:47

@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.com @rickvug on Twitter

How did u do such a great

Direct commented 16 September 2009 at 08:43

How did u do such a great presentation in pdf?

PDF export

jpetso commented 27 September 2009 at 06:32

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).

I'm not sure I understand.

mradcliffe

he/him

English

commented 16 September 2009 at 09:02

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.

Code slush

robertDouglass commented 16 September 2009 at 09:57

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.

Thanks for posting this. Is

dodorama commented 16 September 2009 at 18:33

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

...

sepeck commented 17 September 2009 at 20:57

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}

It makes sense.

dodorama commented 20 September 2009 at 21:11

It makes sense.

Looking forward to...

j0rd commented 17 September 2009 at 19:18

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.

Developing New Site with Drupal 7

Coupon Code Swap commented 20 September 2009 at 03:28

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 :)

I wouldn't

Michelle

she/her

English

Wisconsin, USA

commented 20 September 2009 at 19:01

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.

Michelle

Upgrade

Coupon Code Swap commented 20 September 2009 at 22:39

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

Can't wait!

chrisbeaman commented 20 September 2009 at 19:19

Excited for Drupal 7!

Drupal 7 Code Freeze

websule-old commented 21 September 2009 at 18:59

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.

congrats and happy bug fixes :P

Samuel Lavoie commented 23 September 2009 at 02:36

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? ^_^

I love unstable9

cosmicdreams commented 2 October 2009 at 02:35

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!