Yesterday, I talked about the Gartner hype cycle and how the Drupal 7 release will evolve through it. Now I'd like to generalize it to show how the hype cycle affects the Drupal community -- particularly core developers -- during the development lifecycle of a major release.

Here is the curve of one lifecycle, as seen by Drupal's developers:

Development cycle

The development cycle is like a song, and each phase has its own stanza. Slow motion's lyrics are, "We need more core committers to review patches!" and "Drupal development is so broken!". Patch frenzy wails, "Crap, my patch isn't going to make it in!" and "Wait, we can't freeze the code like this!". User scream is a call-and-response with the market, which sings "You shouldn't release core until contrib is updated" and "I can't believe you're already working on the next version when I haven't even upgraded yet".

Complicating matters is the fact that we're always working on both the current version of Drupal and the next one. (We also maintain the previous version, but its cycle has already finished.) When you overlay Drupal 7 and Drupal 8's cycles, they look something like this:

Development cycle

Adding the two graphs together gives us a new curve that reflects the total picture.

Development cycle

I've put a line where I think we are now. Drupal 7 is on its way into the "Slope of enlightenment", while Drupal 8 is near the beginning of its path.

Unfortunately, a low mood characterizes both of these stages, so the total mood can be discouraging these days. But if you look into the future, it's clear that both Drupal 7 and Drupal 8 are entering a good time. The excitement will only grow until the release of Drupal 8. When will that be? I'll talk about that in my next blog post.


Michelle (not verified):

It's very discouraging. For quite some time after a new release, building on it can be painful if not impossible. But building a new site or doing a major revamp on an old site and using the older version is grating. On my own sites, I just wait it out and am perpetually behind. For people with clients, that may not be an option.

I don't know what the solution is. Holding core until contrib catches up won't work and you can't force contrib to be done any faster. I think it may be that we're just stuck with this endless cycle and have to deal with it.


catch (not verified):

There is a lot of discussion about fast-tracking Drupal 7 core fixes on, what exactly this means is still being worked on, but that should hopefully help to avoid blocking contrib module Drupal 7 stable releases on unresolved core bugs at least partially.

The monthly point releases for D7 will also help with this a bit.

Upgrades of sites to the latest version tend to lag about 6 months if not more behind new site builds on the latest version - it is always trickier to upgrade a site with a lot of custom configuration and/or contrib dependencies than to start from scratch. I wouldn't start a new site on Drupal 6 now. But I wouldn't necessarily recommend upgrading a Drupal 6 site to Drupal 7 yet either unless there was a specific need or it was going to have a major refactor anyway.

Renat (not verified):

Yes, I thought this speech about version lifecycle was there for a good reason. We'll wait next post, though I hope D8 wouldn't be here too soon. I'm exited about extremely promising new features, and I upgraded to D7 some months ago, but contrib has its inertion.

Raf (not verified):

Got to love the "I can't believe you're already working on the next version when I haven't even upgraded yet" team. If you didn't do that, they'd scream that the new release's taking too long :P Putting a separate maintainer (Webchick) actually fixes both concerns -- although there'll always be some who'll scream, no matter what.

catch (not verified):

I've been arguing strongly for a feature freeze when we get over a certain threshold of critical and/or major bugs. A big motivator for making that argument was to avoid another two years of very cold code freeze due to that number getting out of hand. This does require actually fixing the bugs when they start getting out of hand though to keep those temporary freezes as short as possible.

Matthew Davidson (not verified):

I don't see how the "user scream" trough can be significantly ameliorated by anything done in core. From a site builder's perspective, a shorter and more efficient core release cycle just means that the delay in getting stable releases of critical contrib projects will eat up a greater percentage of that release's lifecycle.

Nobody wants to go to a client and say "Hooray! Thanks to increased efficiency within the Drupal project, the platform we're building your web site on will be unsupported even sooner!"

I think the solution, or at least an improvement, is to formalise the relatively successful #D7CX initiative into an "outer core" section of contrib which maintainers can opt into provided their projects meet criteria such as:

  • Pledge for stable release on the date of core major version release.
  • Providing an API or some other functionality that a significant number of other modules depend on.
  • A significant user base.

The aim would be to provide site builders who ask "is Drupal X ready for building sites?", or "is Drupal X ready for upgrading from Drupal X-1?" a better answer than 12 months or more of "aah, kinda, sorta, maybe, it depends".

This wouldn't solve all problems, but if the date when every project in "outer core" has a stable release means 90% of sites can be built/upgraded with relative confidence, it's better than nothing. At best, it will help the developer community identify where the pain points and roadblocks are for site builders and help focus effort. At least, it will provide site builders with the information needed to make their decisions.

Mel (not verified):

Thanks for this post. It sheds light on many things. I know that I've done my fair share of "user scream"ing, but Drupal is definitely in good hands with Dries at the helm. Keep up the the good work.