How I think about Drupal release date planning

Two recent blog posts explained what I think the Drupal development cycle is like; see the Gartner hype cycle and Drupal and the Drupal mood cycle. These thoughts came from living through many major Drupal releases and noticing patterns of developer and user mood as release dates approached and receded. Make sure to read these posts first, before reading this one.

Developers like to release code. "Release early, release often" wrote Eric S. Raymond in his famed essay on open source, The Cathedral and the Bazaar, and that philosophy has facilitated the rise of many open-source projects -- including Drupal. At the same time, many end users dislike change: they would prefer that software versions stay stable as long as possible, because change means work or cost.

Personally, based on listening to a lot of people, I believe that for Drupal 8, the release date should be 18 months after Drupal 7 reaches its Plateau of Productivity.

I think 18 months gives users plenty of time to enjoy Drupal 7's productivity at its peak before facing a possible update. At the same time, it's short enough that developers won't get bored. That said, I'm happy to brainstorm about this more but at least it puts a first stake in the ground.

I can't say how I'll determine that Drupal 7 has reached its Plateau of Productivity. It will be evident in several ways -- the decrease of new Drupal 6 sites, the stability of contributed modules, the number of websites on Drupal 7, the feedback I get when attending Drupal events and so forth. I'll make an announcement at that time to start the clock running.

Right now, I'd predict that the Plateau of Productivity is 6-9 months away, meaning Drupal 8 won't be released for at least another 2 years.


mherchel (not verified):

I agree with you 100% on this. I really think a two year release cycle is too short.

One thing about the "Release early, release often" philosophy is that in the Drupal world, the contrib needs to catch up. And, a real value of Drupal is as a platform for all the great contrib modules that have been and will be released.

Joe (not verified):

Sounds good to me. Right now we have all of our websites in D6 and we aren't looking to upgrade anytime soon. It's doubtful that we will even upgrade our sites to D7... probably just recreate the site in D8 once it is released.

Bartolome Sintes (not verified):

Two years are a long time for an open source project. The trend in other projects is shorter release cycles, not longer. A shorter release cycle means less changes and less compatibility problems. Perhaps Drupal needs something like RedHat/Fedora or Ubuntu LTS/Ubuntu (stable/testing) in order to address different user needs.

Renat (not verified):

I'm not sure Ubuntu is a good example for us. They often calls it "beta for all times" - way too often. I use it still, because it is most popular Linux desktop distro, and I don't want to support fragmentation, but with Drupal it'll be much more hard, because of contrib.

Kris (not verified):

I to would like to see an LTS version of Drupal. For myself as a developer it is enjoyable to pick up onto the next version and for me as a developer the shorter release cycle is perfect. However when I turn over a site to a client this short release cycle isn't always preferred. Many clients put out a nice chunk of change to have a site developed and budget to use it for the next 2-3 years. However those clients also wish that their site stay updated on security patches.

Gábor Hojtsy (not verified):

Drupal is already LTS. Drupal 6 was released about 2 and a half years ago. Dries points out above that Drupal 8 will be released in no earlier than 2 years from now, which is the point that makes Drupal 6 unsupported. That is going to give Drupal 6 a 4.5 year support time in total. Is that not LTS? (Ubuntu's meaning for LTS is 3 years on desktop, 5 years on server).

redndahead (not verified):

If this is the case new features have to be able to come into the 7.x line while d8 is incubated. Two examples of issues that I follow/followed are aliased multisite support and the extension of states

While the states issue seems like it's possible to still get into d7 the policies of committing into d6 does not allow the multisite issue to be added. It needs to be guaranteed that new features that obviously do not break apis, but can introduce new api, are allowed to get in. Maintaining a backport of the d6 version of aliased multisite support has been frustrating since it solves a huge number of issues with multisites, it changes no apis, and it's an improvement with really no downside to current users.

I don't know if it's already been done somewhere, but a well stated policy on new features in the currently released branch would be nice.

Patrick Hayes (not verified):

Eghad! another two years of features-driven config management?! *shudders*

As someone that manages the dev->stage->prod workflow, the day that we get better at config-management can't come fast enough.

The silver lining is that more and more modules have good features-integration either natively or via strongarm. So hopefully a robust features-based ecosystem will be good enough to tide us over for another two years.

Even better would be if, once the config-management patch goes into D8, features v2 offered a similar API to make the transition a smooth one for most modules.

Renat (not verified):

Good, as for me. We have a lot of work to do to fully unleash the power of D7 - and, of course, plenty of work should be done to D8 core itself. Hope there will be less half-ready functions, which do not play well without hacking around the core in contrib.

Ben Barber (not verified):

I'm relatively new to the Drupal community and I came from a Web development shop with a CMS written in Java.

You can "release early, release often" when you have API stability. One of the biggest differences I've seen between the PHP and Java communities is in regards to API stability and backwards-compatibility.

Since the Drupal ecosystem relies heavily on plugins, it would be nice for plugin developers and site maintainers to have more stable APIs to develop against. The more backwards-compatible the API is, the less "code churn" there is in the contrib space after a release.

I say, continue developing features on 7.x but only backwards-compatible changes. The API-breaking changes can wait 2 years. But maybe some new features can't.

znat (not verified):

I agree with Bartolome - we need to aim for shorter release cycles and less compatibility issues.

I seriously don't want to wait for 2013 to see config management just starting to be available.

catch (not verified):

You can't have major new APIs like the configuration management initiative, shorter release cycles, and backwards compatibility - these are mutually exclusive.

Those APIs take time to develop, and once the initial work is in there is a long follow-up process of converting core to use them - having a configuration API in core doesn't mean much if most core modules are still doing using custom tables for configuration. It is necessary to break backwards compatibility there for people to actually be able to use the new feature (if you have contrib modules still using variable_set() then you'd still need features/strongarm in D8, which won't be fun).

A good example of the time needed for things to bake in would be the Field API in Drupal 7, the original patch went in on Feb 4th 2009, but there were many, many changes both to the API itself and to the rest of core in the ~2 years prior to the Drupal 7 release. There was also a long time between the new database layer being added and the full conversion of core to use it. In both cases this was a good thing since a lot of issues got ironed out.

It should be possible to backport small API additions and performance improvements to Drupal 7 as well as regular bug fixes (and even bug fixes will be significantly easier to backport than they have been with D6 due to automated tests).

For larger stuff, there is also the potential option of backporting to a contrib module, is a great example of this.

Finally, part of the reason the Drupal 7 cycle was longer than expected was that a lot of bug reports were accumulated during the release, and it took a long time to triage and fix them during code freeze. You can help avoid that situation happening againright now by triaging the bug reports against Drupal 7 and 8 - this counts for whether you can write a single line of PHP or not. The tighter that queue is kept under control, the more chance there is we can release when we want to (and to get back on topic, a couple of years sounds about right to me).

Marty (not verified):

I manage almost a hundred sites (college courses) in a multisite configuration. I'm still migrating some to Drupal 6. I shudder to think about have to migrate all 100 again in 1.5 years when I'll probably have 130 sites. I don't mind new versions coming out but retiring the old one is kind of annoying if it occurs very frequently. New versions of software might be good for developers but for site maintainers it's a pain.

moshe weitzman (not verified):

We hear this a lot. And it doesn't make a lot of sense to me.

Why are you so compelled to upgrade? If I had 130 sites, I don't think I would ever upgrade them. Maybe out of necessity I would upgrade the still active ones after Drupal 6 goes End Of Life. That's approximately 5 years. Is there something on the web you can't do with D6 that you can do on D7? That seems unlikely.

Drupal is at a point now where you can build what you need to on any modern version of Drupal. The need for major upgrades is quite low, IMO.

Marty (not verified):

But if Dries feels D7 reaches it plateau of productivity in 6 months and D8 is released 18 months after that, I'm looking at 2 more years, not 5, when D6 goes end of life. Then I have over 100 sites potentially vulnerable to security problems.

catch (not verified):

Drupal 6.0 was released on the 13th February 2008, so that is 5 years in total.

The main issue with EOL is not so much security patches for Drupal core - if that was the only issue it would not be a massive drain to support three releases for 6 months or so after the latest release is out. I think there's only been one security release of core since Drupal 5 reached EOL, and if there was a six month or even a year window, we'd not be too far from the end of that.

The real issue there is contrib modules - hardly anyone wants to support Drupal 5 versions of their modules, and having the security team do core security releases of Drupal 5 core would mean very little if there is no support for contrib. That is not supporting one project for an extra few months, but several thousand.

However the known install base of Drupal 6 is a lot larger, and there is more usable statistics about how it's distributed due to, it will be interesting to see if the number of Drupal 6 sites starts to reduce drastically as Drupal 7 uptake continues, or whether it will stay more or less static (as it has since 7.0 release).

Regardless of this, every time the issue of short vs. long release cycles comes up there are three camps:

1. People who want very short release cycles becuase they want new features quickly - this position doesnt make any logical sense to me since the new features have to actually be worked on before they can be released, and that takes time.

2. People who think the current release cycle (2-3 years) is fine. This includes me except I wish it had been a bit more voluntary with Drupal 7 rather than imposed by code debt.

3. People who want both longer release cycles, and LTS support for older releases. This is a reasonable position, but people who want the support for older releases need to step up and help make that actually happen. It is not reasonable to expect volunteers to maintain outdated versions of software 2-3 versions back, for years after they have stopped using it themselves - which is what that position amounts to unless it is backed by offers of time or money.

ChX (not verified):

There certainly are conflicting visions on this but Dries previously posted he is open investigating backporting new features to D7. dww and I have added versioned dependencies to D7. With these said, I am sure I can survive two more years without tearing out the rest of my hair.

juliangb (not verified):

I think it is counterproductive to announce a proposed release date so far away, considering the great work setting up D8 in other respects.

A shorter release cycle seems necessary to give us the flexibility to cope with the ever changing web.

Barrett (not verified):

You can't further shorten the core relase cycle without causing even bigger problems with contrib. We're several months past the release of 7, and yet several critical (in my experience) modules (e.g., Panels, Rules, Views) still don't have a production release for D7. Getting a production release of D8 that supports better configuration management is wonderful, but until there's a wide enough contrib base to support it the effort will be for naught.

The D7CX pledge was a noble effort, but it doesn't seem to have lived up to it's promise. We, as a community, need to come up with a way to get contrib up to core more rapidly or it will continue to be an anchor holding back progress.