There will be a Drupal 9, and here is why

Earlier this week Steve Burge posted the intriguingly titled There Will Never be a Drupal 9. While that sure makes you click on the article, it is not quite true.

Drupal 8.0.0 made several big changes but among the biggest is the adoption of semantic versioning with scheduled releases.

Scheduled releases were decided to happen around twice a year. And indeed, Drupal 8.1.0 was released on time, Drupal 8.2.0 is in beta and Drupal 8.3.x is already open for development and got some changes committed that Drupal 8.2.x will never have. So this works pretty well so far.

As for semantic versioning, that is not a Drupalism either, see http://semver.org/. It basically means that we have three levels of version numbers now with clearly defined roles. We increment the last number when we make backwards compatible bug fixes. We increment the middle number when we add new functionality in a backwards compatible way. We did that with 8.1.0 and are about to do it with 8.2.0 later this year. And we would increment the first number (go from 8.x.x to 9.0.0) when we make backwards incompatible changes.

So long as you are on some version of Drupal 8, things need to be backwards compatible, so we can just add new things. This still allows us to modernize APIs by extending an old one in a backwards compatible way or introducing a new modern API alongside an old one and deprecate (but not remove!) the old one. This means that after a while there may be multiple parallel APIs to send emails, create routes, migrate content, expose web services and so on, and it will be an increasingly bigger mess.

There must be a balance between increasing that mess in the interest of backwards compatibility and cleaning it up to make developer's lives easier, software faster, tests easier to write and faster to run and so on. Given that the new APIs deprecate the old ones, developers are informed about upcoming changes ahead of time, and should have plenty of time to adapt their modules, themes, distributions. There may even be changes that are not possible in Drupal 8 with parallel APIs, but we don't yet have an example of that.

After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed. What would make you move to Drupal 9 then? Well, new Drupal 8 improvements would stop happening and Drupal 9.1 will have new features again.

While this is not a policy set in stone, Dries Buytaert had this to say about the topic right after his DrupalCon Barcelona keynote in the Q&A almost a year ago:

Read more about and discuss when Drupal 9 may be open at https://www.drupal.org/node/2608062

Comments

Roger Nyman's picture

Some really great clarifications here. Thanks.

Eelke Blok's picture

I agree with everything you're saying. One interesting dynamic here is the consequences for Drupal 7 when Drupal 9 is released, because (if the policies remain the same), that will mean support for Drupal 7 ends. I wonder if that will enter the discussion at all (and whether it should; maybe that's a consideration to possibly make an exception for Drupal 7, in this regard, in order to not complicate the decision when to go for Drupal 9).

Gábor Hojtsy's picture

These points are also already discussed in terms of when Drupal 7 goes to get security fixes only (https://www.drupal.org/node/2598662) and when it goes totally unsupported (https://www.drupal.org/node/2608496). There are even less agreed on details in that area.

Arne's picture

"After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed."

I think that's the important part why there "must" be a 9 release sometime in the future.
And maybe Drupal 9 will be re-written on top of another base-system, e.g. instead of PHP, Symphony, with NodeJS or a newer "thing" that is much better than what is en vogue right now.

Gábor Hojtsy's picture

So much as backwards compatibility allows going forward in Drupal 9, many things may be possible.

Spudley's picture

It's wishful thinking to imagine that Drupal could be rewritten in an entirely different platform and keep the Drupal name. In any case, what is "en vogue right now" is rarely the best option for long-term stability. In any case, the PHP language is actually becoming a very solid platform now; most of the things that gave it a bad reputation have been deprecated or fixed, and while there are still some issues, that much could be said for virtually every language.

andrewmacpherson's picture

the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed.

That's exactly how the Ember 2.0 release worked - a clear out of everything marked as deprecated.

Eelke Blok's picture

Although a complete rewrite can't be ruled out ever, I would be very surprised if Drupal 9 would turn out to be one (and to be perfectly blunt, I don't think Drupal could survive another major rewrite - that's not to say it couldn't stick around for a long time on the current, more evolutionary path).

I am actually looking forward to a much more flexible upgrade experience. If modules are kept "up to date" with API deprecation throughout the D8 lifecycle, an upgrade to D9 is likely to be somewhat of an anti-climax for us old Drupal folk. No more entire site rebuilds to keep up with the latest and greatest Drupal. Yay! Of course, that might turn out to be somewhat of a big if, especially for more obscure modules.

Gábor Hojtsy's picture

It clearly depends on module developers buying in this system which begins with a need for more people to even understand it. That was the reason for my post to counter some heavy misunderstandings.

Spudley's picture

Another reason why we are certain to need major version numbers in the future is because of the need to keep up with dependencies.

Drupal 8 is dependant on Symphony. But Symphony is a separately maintained project; Drupal has no little or say over what changes are made to it. So when Symphony releases a new version that is backward incompatible, then Drupal is likely to be forced to do likewise.

This wouldn't need to be forced in the sense of being rushed into it -- The Symphony project would continue to support their old version for some time, just as Drupal does. But that support won't continue indefinitely, so Drupal would need to do a managed upgrade at some point, which would mean a major version number increment.

In all probability, this would be managed in such a way that the Drupal devs could use the major version change to introduce other BC breaks, such as dropping deprecated features, as mentioned in the original post.

Manish Champsee's picture

I might be taking your post a little too literally, but I would suggest an approach similar to PHP where deprecated items are removed after a certain amount of time. I don't think we would want a situation where something that gets deprecated in 8.2 is continued to be supported until Drupal 9, while something that gets deprecated in the 8.x release just prior to Drupal 9, has people scrambling to change their modules in order to support D9.

I realize that it may break commitments already made about keeping 8.x backwards compatible, but I think it would be an easier approach for the community then supporting everything that got deprecated along the way and then getting rid of all support for them in one fell swoop.

Gábor Hojtsy's picture

Well, we decided to not make up our own system but instead rely on http://semver.org/, with which your suggestion is not compatible with. Depending on how much we add on in Drupal 8 and consequently how much we depreciate, Drupal 9 may come sooner or later IMHO.

Manish Champsee's picture

Fair point. I see your point.

Eelke Blok's picture

Just addressing the concern that something is deprecated "shortly" (we might have to define what that means) before the release of the next major version, it could be decided to keep it around for another round, so to say. That would have to be considered on a case-by-case basis (and I suppose it should only really be considered if rewriting stuff to the replacement is extremely non-trivial). All I'm really saying is, "Remove depricated items in the next major release" doesn't have to become a dogma, it should remain practical.

Gábor Hojtsy's picture

I agree, makes sense. I don't expect huge new additions so late in the cycle, but we don't know really yet at this point.

Add new comment