There Will Never Be a Drupal 9
Yes, that’s a big statement in the title, so let me explain.
Lots of OSTraining customers are looking into Drupal 8 and they have questions about Drupal 8’s future. If they invest in the platform today, how long will that investment last?
This is just my personal opinion, but I think an investment in Drupal 8 will last a long, long time.
Drupal 8 took five years. It was a mammoth undertaking, and no-one in the Drupal community has the energy for a similar re-write. Drupal 9, if it ever does arrive, will be a far smaller update.
We’re seeing Drupal developers get comfortable with much smaller releases. Drupal 8.1 arrived in April and had new features including, migration improvements and the BigPipe module.
The Beta version of Drupal 8.2 has arrived. The aim with 8.2 is to stabilize some experimental modules, plus improve workflow and usability.
Usability improvements for blocks may arrive with Drupal 8.3.
There’s already talk of a new core theme with Drupal 8.4.
So, Drupal is adjusting successfully to the new reality. Big releases are probably history. Drupal’s future is in regular, small, backwards-compatible releases.
And Drupal 9? We’re more likely to see Drupal 8.9 before we see Drupal 9. And that’s a good thing for Drupal.
Update #1: Gábor Hojtsy, who lead Drupal 8’s multilingual initiative, wrote a response. Gabor’s ideas sound similar to the ideas in this article, “the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed.”
Update #2: I’ve been wrong many times, but did get this one right. Six months after this post, Dries has said:
Drupal 9.0 should be almost identical to the last Drupal 8 release … Updating from Drupal 8’s latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8.
Update #3: Yes, this post did have a click-bait headline. There will be a Drupal 9. For those that didn’t get it, my point is that Drupal 8 broke the current versioning system. Drupal 9 must take a very different approach.
There will probably be a Drupal 9, but it’s arrival will be pretty boring.
I agree that we’re seeing and are likely to continue to see significant advancement in Drupal 8. When new functionality lands within the core offering we’ll likely see that arrive as experimental modules in a minor revision of Drupal. These minor revisions will land around April or October of each year.
And if Drupal 9 ever comes, it probably won’t have new fancy features, it’ll just be a solidifying of existing features and the removal of a backwards compatibility layer. This is because we can add new code and functionality without breaking backwards compatibility.
Great points, Chris.
If Drupal 9 ever arrives it would be mark a much smaller milestone.
Between Magento 2 and Drupal 8, I don’t think we’ll ever see such massive half-decade re-writes again.
This is a really great thing as we can stop talking about “Drupal X” and simply focus on Drupal. Drupal ∞ should be what comes after “Drupal 8”. Lets just lay that 8 on its side.
@ryanaslett I like it!
From what I heard at the Con, some Drupal 8.x release might be declared as D9 the day it breaks with backward compatibility. This was a guess from a Dev, not a fact, but sounds good to me;-)
@mazze Interesting. I’m sceptical whether they actually take such a big risk … another backwards compatibility would be a hard sell.
This is exactly what the core committers plan:
– Drupal 8 introduces new features and deprecates others with a notice that Drupal 9 will remove the old BC layers.
– Contrib code has ample of time to adjust to the new APIs
– Drupal 9.0 simply removes the BC layers, so Drupal 9 == Drupal 8.Y with BC removed (and that will be announced way in advance)
– If contrib was maintained properly, they do already not used deprecated APIs and such directly are D9 compatible, etc.
This is a new way of thinking mainly and e.g. exactly like the Symfony 3.0 release worked.
The reason we need to remove BC at some point is to remove old cruft as else you just keep on piling up.
In theory all of this would have been possible with D7 as well and to an extend we start applying that mindset there too (with the limited scope we have there), but it mainly is a policy and way of thinking and not dictated by the new code or anything.
That is the important part.
@fabianfranz Thanks indeed. That kind of approach is an excellent step forward.
The massive rewrite that resulted in D8 is far from being considered complete. There are already lots of @deprecated tags in the code and that number will grow fast. So my guess is that sooner than later we will see a D9 that further cleans up the technical dept and non-OO code. So D9 will, as others already commented, probably not contain many new features but will focus only on this internal stuff as far as these changes are backwards incompatible.
@fietserwin Yes, good points, although it’s going to be a very, very, brave decision to break backwards compatibility any time in the next few years.
You’re assuming that any BC break means another Drupal 8 level “rewrite all the things” change. I agree, few people well have the stomach for that again any time soon, which is good. The 8.x line has a lot of life left to it.
But we just deprecated drupal_set_message I’m favor of a method that is injectable and testable. That’s good. How long shall we now keep the ugly and untestable function around? A year? 2? 5?
At some point that will be removed, it has to be. That will happen in a release called 9.0. Of that I am 100% absolutely certain. At some point we’ll also want to start using language features that came out after 2013 (in 5.5, which is already deprecated). That will also require a 9.0.
As a trainer, what you’re really arguing is that another earth-shattering architectural change is unlikely any time soon, so time (and money) spent on Drupal 8 training now is a good investment. I’m that I completely agree. 🙂
But that’s a far cry from saying there will never again be a BC break in Drupal, or that the architecture will never again change. Both are patently false, and it’s disingenuous and harmful to suggest so.
@larrygarfield Thanks Larry.
When talking with customers I don’t promise either of those things but I do say something on the lines of:
“There are no guarantees, but the move to Drupal 8 was tough enough that something that big is unlikely to happen again. Future updates will be much smoother.”
Maybe as a writer, I didn’t do a good enough of flipping the article from Drupal 9 to focus on the positive aspects of Drupal 8.
So, expanding on the second part of the article quickly … what I am hearing from students is that the new D8 release cycle is reassuring. It gives them confidence that a lot of current issues are solvable. It gives them confidence that any future BC breaks can be minimized. I’m looking forward to writing about 8.2 next week.
The advantage of deprecate then remove however is that the BC layer can in theory be moved to contrib (with no guarantees on a best effort basis).
At least for simple things like drupal_set_message() – if anyone still really cares about it …
Upgrading to Symfony 4 will be a backwards compatibility break, and by the time Symfony 4 is released there will be lots of deprecated Drupal 8 features that we want to remove, so I predict a Drupal 9 release some time in the year after Symfony 4 is released, probably Symfony in 2018 and Drupal 9 in 2019.
When Drupal 9 is released, many contrib modules will already support it, because they were written using only for Drupal 8.7’s undeprecated APIs.
@ianthomas_uk Great points. Yes, Drupal 8 does have a lot of feature releases between now and Symfony 4. That’s enough time to mitigate a lot of potential BC problems.
Hopefully you are right and there will never be a Drupal 9 … non-backward-compatible changes are horrible (but ok, perhaps will be necessary again one day…) In a perfect world there will simply be Drupal (8) 😉
@julianpustkuchen Yep, Ryan put it nicely in a comment above: “Drupal ∞ should be what comes after “Drupal 8″”
Drupal 8 (7,6,5…) sucks so much ,why would there ever be a 9. Drupal is a dying framework/cms
Posts that don’t age well. https://www.drupal.org/documentation/9
All other features of this version coincide with Drupal version 8.9.0. And that is why, to ensure compatibility with previously used extensions, you will need to make only small changes.