Understanding The Drupal 8 and 9 Release Cycle
In preparation for the release of Drupal 8, big changes were made to the Drupal release cycle.
The changes started with Drupal 8, but are going to impact almost all current and future versions.
In this blog post, I’ll give you a short, plain-English overview of the changes.
I’ll show how the changes will impact users of Drupal 6, 7, 8 and 9.
What has changed for Drupal 8?
- Drupal 8 is not fixed and unchanging. It will evolve over time with the addition of new features.
- New Drupal 8 releases will come out every 6 months. Versions 8.1 and 8.2 have already shipped with new features. 8.3 and 8.4 are due in 2017.
- The latest release will be the only one that’s supported.
- The end of the process will be a Long Term Support version or LTS. When that LTS arrives, no new features will be added, only security fixes.
Here’s a graphical overview of how the releases work:
Here’s the big change: new features can now be added after the 8.0 release.
One of the downsides to Drupal’s old release cycle is that new features couldn’t be added.
Drupal 7 was essentially finished in 2010 (although it was released the next year). So no new features have been added to Drupal since 2010.
That feature freeze is great for enterprise customers, but very clunky for today’s software developers who are used to working iteratively, making fast and regular updates.
In the proposal, Dries said that the new release cycle allows them to use “a more agile development approach of getting smaller changes out faster, seeing how they do, and making further changes based on real-world data. ”
In the comments, Jesse Beach (who is responsible for much of the work on Drupal’s UI) said, “Building a usable UI requires numerous iterations and we really don’t get those over large major release cycles.”
What does this mean for Drupal 9?
- Drupal 9 will only start development when the the core team have completed a new feature big enough to justify a new version.
- Drupal 9 should arrive on a normal schedule, which is 2 or 3 years after Drupal 8.
What does this mean for Drupal 6 and 7?
Wait, why are we bringing 6 and 7 into this?
Because this new release cycle may be good news for owners of Drupal 6 and 7 sites:
- Drupal 6 would be security supported until 8’s LTS rather than only until 8.0.
- Drupal 7 would be security supported until 9’s LTS rather than only until 9.0.
So this change could mean an extra 18 months of fixes. It’s possible that this could mean Drupal 7 support until 2019 or 2020.
What does this mean for you building sites in the future?
Be very careful with the selection and quantity of modules you use in Drupal 8. This is good practice anyway, but will become a more formal recommendation with Drupal 8.
Here’s the advice from the release cycle proposal:
“Don’t use custom modules; stick to only contrib modules that are adequately maintained. Or, if your site requires custom code, make sure the developers you hire know to limit their code to only accessing APIs marked as stable.”
In other words, changes may happen between Drupal 8.0 and the Drupal 8 LTS. If you build you own modules or use poorly supported custom modules, watch carefully in case updates cause problems.
Wait, doesn’t this all sounds very familiar?
Yes, this release cycle is very similar to those adopted by Joomla and Typo3 amongst others.
This release cycle is one form of Semantic Versioning which is adopted by many products: http://semver.org.
Can I found out more about this change?
Yes, this video from Margaret Plett at Drupal 8 Day is a great introduction to the thinking behind the new release cycle.
Hope it works better for Drupal than it did (does) for Joomla.
I really think where we are heading is one release with lots of little packages, each with their own version, and a push for API’s that expand (meaning, always BC.) Going to be tough but where we are at is very costly.
for Joomla it worked fantastic!
I was wondering when Drupal will start getting some sense…
“Here’s the big change: new features can now be added after the 8.0 release…. One of the downsides to Drupal’s old release cycle is that new features couldn’t be added… Drupal 7 was essentially finished in 2010 (although it was released
the next year). So no new features have been added to Drupal since 2010.”
The above is incorrect. Many new features have been added to Drupal 7 after the 7.0 release a few years ago. Here are a couple recent examples from the last several months:
The adopted proposal doesn’t change this at all for Drupal 8; the policy regarding adding new features will (so far, at least) still be exactly as documented here: [url=https://drupal.org/node/1527558]https://drupal.org/node/152…[/url]
What the proposal does do is a couple things:
1. By holding off on opening Drupal 9 development until absolutely necessary, it aims to encourage more people to propose features for Drupal 8.0+ in practice.
2. It proposes a more meaningful numbering scheme for releases so you can tell which ones have new features and which ones don’t.
Also, the idea of extending Drupal 6 security support past the Drupal 8.0 release (and consequently the idea of doing the equivalent for Drupal 7 after Drupal 9 comes out) is still being actively discussed, at [url=https://drupal.org/node/2136029]https://drupal.org/node/213…[/url] and elsewhere. Right now, the Drupal security team simply doesn’t have the resources to be able to do that; but maybe with an influx of new volunteers it eventually will 🙂
Thanks for the clarifying points, David
Regaring the first point, maybe it would be more accurate to say “new major features”.
For example, this new release cycle enabled Joomla to add revisions in one minor release and then a RAD Framework and an App Store in another.
Those are orders of magnitude larger than anything Drupal or Joomla were able to add under the older release cycles.
I wouldn’t be surprised to see similarly large features arrive with Drupal 8.1 or 8.2.
You’re right, there haven’t been many major features that have made it in since the Drupal 7 release (although there’s no reason they can’t, and in some ways a major feature should even be easier to get in than a minor one; if the major feature is implemented as a separate module it doesn’t run a risk of breaking existing sites when it’s deployed 🙂
It will be interesting to see if things are different with Drupal 8. The difficulty with getting a major feature in post-release, though, is that it needs to be very well-reviewed and well-tested (since it will go out to production websites on a much shorter timeframe than a pre-release feature). That won’t change, but perhaps the longer minor release cycles planned for Drupal 8 will help here, since it will give a bit more time for features to be tested after they are added but before they appear on live sites.
I found a good example here: [url=http://www.ostraining.com/blog/drupal/drupal-8-november-2013/#comment-1141187969]http://www.ostraining.com/b…[/url]
With the Migrate features, they don’t want them to hold up the 8.0 release. So there’s a good chance that Migrate won’t arrive until 8.1.
Wow looks a lot like another big CMS project I know and love. I wonder why they didn’t want to go with semantic versioning..
I suspect cultural issues may play a role, as they did with Joomla.
Once you have big community expectations and needs that have built up over years, it’ll be hard to adopt pure semantic versioning.