The promise of making drupal upgrades easy

One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) has also held back Drupal's momentum. In an ideal world, we'd be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we've found a way to do both!

Upgrading from Drupal 8.2 to Drupal 8.3

Before we can talk about the upgrade path to Drupal 9, it's important to understand how we do releases in Drupal 8. With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizable advances in functionality every six months. Furthermore, we committed to providing a smooth upgrade for modules, themes, and distributions from one six-month release to the next.

This new approach is starting to work really well. With the 8.1 and 8.2 updates behind us and 8.3 close to release, we have added some stable improvements like BigPipe and a new status report page, as well as experimental improvements for outside-in, workflows, layouts, and more. We also plan to add important media improvements in 8.4.

Most importantly, upgrading from 8.2 to 8.3 for these new features is not much more complicated than simply updating for a bugfix or security release.

Upgrading from Drupal 8 to Drupal 9

After a lot of discussion among the Drupal core committers and developers, and studying projects like Symfony, we believe that the advantages of Drupal's minor upgrade model (e.g. from Drupal 8.2 to Drupal 8.3) can be translated to major upgrades (e.g. from Drupal 8 to Drupal 9). We see a way to keep innovating while providing a smooth upgrade path and learning curve from Drupal 8 to Drupal 9.

Here is how we will accomplish this: we will continue to introduce new features and backwards-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backwards compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.

This means that Drupal 9.0 should be almost identical to the last Drupal 8 release, minus the deprecated code. It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9. Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8. It also means that Drupal 9 gives us a clean slate to start innovating more rapidly again.

Why would you upgrade to Drupal 9 then? For the great new features in 9.1. No more features will be added to Drupal 8 after Drupal 9.0. Instead, they will go into Drupal 9.1, 9.2, and so on.

To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release. So long as we make these changes before Drupal 9 and contributed or custom modules take advantage of the latest Drupal 8 APIs, up-to-date sites and modules may just begin using 9.0.0 the day it is is released.

What does this mean for Drupal 7 users?

If you are one of the more than a million sites successfully running on Drupal 7, you might only have one more big upgrade ahead of you.

If you are planning to migrate directly from Drupal 7 to Drupal 9, you should reconsider that approach. In this new model, it might be more beneficial to upgrade to Drupal 8. Once you’ve migrated your site to Drupal 8, subsequent upgrades will be much simpler.

We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017.

What does this mean for Drupal developers?

If you are a module or theme developer, you can continually update to the latest APIs each minor release. Avoid using deprecated code and your module will be compatible with Drupal 9 the day Drupal 9 is released. We have plans to make it easy for developers to identify and update deprecated code.

What does this mean for Drupal core contributors?

If you are a Drupal core contributor and want to introduce new improvements in Drupal core, Drupal 8 is the place to do it! With backwards compatibility layers, even pretty big changes are possible in Drupal 8.

When will Drupal 9 will be released?

We don't know yet, but it shouldn't matter as much either. Innovative Drupal 8 releases will go out on schedule every six months and upgrading to Drupal 9 should become easy. I don't believe we will release Drupal 9 any time soon; we have plenty of features in the works for Drupal 8. Once we know more, we'll follow up with more details.

Thank you

Special thanks to Alex Bronstein, Alex Pott, Gábor Hojtsy, Nathaniel Catchpole and Jess (xjm) for their contributions to this post.


Tanay Sai (not verified):

This is cool. A feature on Coder module or Drupal console, or to the new core report page, that scans modules and themes code for deprecated APIs will be a great add-on to make it easy for contrib maintainers to ensure they keep their code remains updated and always ready for D9.

Further, d.o could start doing this, where all published modules and themes are scanned monthly and the maintainer would receive a notification, as well as an issue is automatically created on the project's issue queue with the details of deprecated code that should be replaced.

Neil Drumm (not verified):’s DrupalCI is already running Coder’s rules for every test run. For example, click through to any of the results at and click the message like “857 coding standards messages”

xjm (not verified):


"Further, d.o could start doing this, where all published modules and themes are scanned monthly and the maintainer would receive a notification, as well as an issue is automatically created on the project's issue queue with the details of deprecated code that should be replaced."

We also already plan to make the automated testing system report failures when deprecated code is used unless the test is specifically marked as a test for deprecated code, so that should help too!

David Thorne (not verified):

This is great. My colleague and I were also discussing (His idea, I can't take the credit) whether there is any merit to showing badges/icons on the project page showing things like adherence to coding standards? Whilst no guarantee of quality, poor testability, poor adherence to known standards are often indicative of a code smell ( which could help weed out poorer modules over time?

Hamza Zia (not verified):

Great changes! The steep learning curve and the difficulty of upgrading to another major version have usually been the main barrier preventing users from taking the jump. With this new model, more and more people will take the leap and be at home with it. Looking forward to upcoming updates more now :).

Michael (not verified):

This looks like a really cool approach to handling upgrades going further - I am looking forward especially to seeing the Drupal 7 - Drupal 8 upgrade release. That is going to be pretty key. Any thoughts on migration from other platforms to Drupal? The issue to me is about having a simple approach (rules-based?) to migrating content and site structure such as URLs, etc. But this is really cool stuff, and whilst Drupal 8 has its challenges for sure, it definitely has to be the most innovative release of Drupal to date and the ideas for improving the platform just keep on flowing ... :)

Massimo (not verified):

The assumption here is that deprecated code can live together with new APIs. If this is the case, then just moving deprecated code to optional modules would keep Drupal clean with no need for a Drupal 9 ...

xjm (not verified):

Interesting idea, but I don't think that works. Moving the deprecated code to optional modules would still be a backwards compatibility break, because the namespaces etc. would change and core by default would no long enable it by default, so sites and modules would still have to make changes (which is the definition of backwards compatibility break really). Also, a lot of the code is in required core subsystems, so the optional module solution isn't there either. Finally, one of the goals in removing deprecated code is to reduce the burden of maintaining it, and that would not meet this goal.

phenaproxima (not verified):

"Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9."

I like the second sentence of that passage, but the first gives me pause. How are we going to know when we have too much deprecated code in Drupal 8? By what metric will we determine that? We already have an awful lot of it. Migrate is especially bogged down with backwards compatibility concerns and some truly icky code that cannot be refactored for fear of breaking BC.

And how about moving old, crufty (but not yet deprecated!) modules out of core? Can we start deprecating entire modules? IMHO, Color, Forum, Aggregator, Ban, and others really shouldn't be in core anymore. I think it would also be a shame for Drupal 9 to be released with experimental modules that didn't manage to reach stability during the 8.x cycle.

I would also like to see Drupal 9 break completely away from the current packaging systems. I think all modules should use composer.json as their one and only info file, and all modules should be available only from's Composer repository. Composer should be the only way to build a Drupal code base.

Anyway, that's my wish list. That said, I'm a big fan of continuous innovation and I think that embracing semver is one of the smartest things Drupal has ever done! :)

Mixologic (not verified):

"Composer should be the only way to build a Drupal code base."

In principle this is sound, but we should probably address the user experience of actually constructing a site that not only abstracts away an implementation detail like composer but goes one step further and encompasses everything that is required to build an entire Drupal code base. PHP is only half the battle, so we need it to address the front end libraries + css framework tools/fonts etc as well. So, a site building tool that can manage NPM/Bower/Composer, perhaps even run sass/less, and maybe even execute gulp/grunt/phing tasks that is wrapped in a higher level interface (like module updater, but better) that addresses the needs of somebody constructing a site.

We also have aspects of the product that are of very high value to certain market segments, like multisites, and we don't yet have a good "best practices for how to use composer in a multisite environment" - This tool could also help address that.

Most codebases also require ongoing maintenance, and demand new features, so this tool would also probably need to address the issues of maintenance and upgrades. It could be a great opportunity to introduce things like automatic, secure updates, while simultaneously improving our resource usage for the updates api.

But like @DamienMcKenna mentioned elsewhere in this thread, we definitely do not want to be "actively hostile towards non-developers and non-experts", and I think if we put some design focus on a great experience for that category of folks, we can come up with something that makes everybody delighted to continue to use Drupal, as well as increase further adoption.

catch (not verified):

@phenaproxima Experimental modules are already in a situation where they'll be removed if they're not stable within two minor releases (with a degree of flexibility), so nothing should be sitting in core as experimental for years.

On removing stable modules, there's nothing stopping us marking entire modules in 8.x deprecated, but people need to open (or revive) the issues to do that, and those decisions should probably happen in the ideas queue at this point.

For Drupal 9 to use composer.json instead of .info.yml, we'd have to support a module using composer.json in Drupal 8 first (and deprecated .info.yml) - so like the post says, if people want 9.x to do something differently, the best (and really only) way is to implement support in a minor 8.x release.

For identifying when we've got too much bc, that's hard and it's not something we've had to do before. Adding support to report @deprecated usages, making core actually up-to-date and not using its own deprecated code etc. will help a bit to flush it out a bit hopefully.

Peter Janes (not verified):

Many thanks for this approach (and for bringing Drupal to the world, at all)!

Can you elaborate on composer plans?

I am currently stuck in the situation with D8 that certain modules require composer for installation (e.g. address), and this breaks my Softaculous backup runs (obviously by overwriting the vendor folder). Looks like drush has similar issues.

Clear guidance on composer usage (or just helpful workaround explanations) would be much appreciated.

Damien McKenna (not verified):

If Composer was the only way to install Drupal, without support for this via Update Manager ( how many more people would drop Drupal, how much more would its PR suffer for the perception of it being too elitist, that its leaders being actively hostile towards non-developers and non-experts? This goes directly against some of the comments Dries has made in Driesnotes before. Lets continue this discussion in

mradcliffe (not verified):

"It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9."

This is great in practice, but it is hard to take advantage of Drupal 8 APIs when the backwards-compatibility policy is explicitly not backwards-compatible by any other definition of the term. I can no longer rely on Drupal core to be stable if even public methods or initialize methods are no longer backwards-compatible.

Experimental modules are hit-or-miss in terms of stability. We say that they are experimental meaning "buyer beware", but we also say that certain experimental modules are required and encouraged to be used. This is puts users in a Catch-22.

How can we possibly recommend upgrading to Drupal 8 when Migrate is an experimental, unsupported module? We want people to use and migrate to Drupal 8, but no sane person should consider it if their site data is at significant risk because of the state of the upgrade path.

Personally I think that in order for @Dries' vision to work we need to

  1. Get Migrate stable and locked down ASAP so that there are no surprises and we provide a reliable and consistent upgrade path.
  2. Actually commit to backwards-compatibility instead of a the false meaning of backwards-compatibility in the current policy draft. We should care about not breaking people's sites or contrib. modules instead of the current "buyer beware" approach to backwards compatibility and experimental modules like Migrate.
xjm (not verified):

@mradcliffe, we specifically do *not* encourage people to use experimental modules (if you ever see someone doing so, please correct them) and their use is certainly not required. Experimental modules are designated as pre-release versions, and therefore there is no expectation of BC for them. This is clearly documented on which is linked in a big yellow warning any time an experimental module is enabled and on the status report when one is running. Installing them is the same as downloading and running an alpha or a -dev tarball of a contributed module.

Reading between the lines of your post, I gather you had a frustrating experience with a BC break in the Migrate API. (I can see how in a sense Migrate can be called "required", but it is not required for new sites and 8.0.0 was intended primarily for new sites. If we'd required Migrate to be stable before releasing Drupal 8, well, Drupal 8 would not have been released in 2015 for sure.) I think we all expected Migrate to be stable sooner but many contributors are working really hard on stabilizing it, which is why the BC break that may have frustrated you happened. It's a sign of work being done to stabilize it, which is what you want.

Migrate was marked beta stability for 8.3.0, so the API itself should be mostly backwards-compatible from 8.3.0 on (though it may still change if there is a serious issue). Migrate Drupal on the other hand is still alpha so may still have BC breaks as needed to resolve issues before it becomes stable.

The post above says:

"To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release."


"We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017."

So I believe that covers your point with regard to the fact that we can't expect users to upgrade before the migration path is fully supported.

Also, as stated above, we won't be carrying experimental modules over from major to major; they have to stabilize within one year or get removed. (Which is a much bigger BC break than the ones that may have affected you, so really, do not use them before they're stable unless you're willing to risk *that* upgrade path.) Migration is an exception from this policy, but as the post states, completing Migrate and the Migration path is a requirement to support the continuous upgrade path, and fully supported Migrate with D8 sources is a prerequisite set by the release managers to opening the 9.x branch, so the concerns about experimental modules are not relevant to the continuous upgrade path.

So, in response to your suggestions, (1) is indeed a top priority and a requirement, as stated (and we also put it at the top of for the upcoming minor), and (2) is not applicable because we do provide BC for public APIs, just not in experimental modules, which will not be a part of the major version upgrade anyway. Thanks!

Jose Reyero (not verified):

It is an interesting idea but really, it is much easier said than done.

We can keep building up the API deprecating some functions/classes and adding some others, but only up to some point before the mess starts piling up. Moreover, is Drupal API all public methods exposed by classes? Or it is only a subset of them?. Can we trust array structures being passed around to be backwards compatible? (Many modules rely on that).

The big issue, as I see it is there's no Drupal API. Drupal is an API. So there's very little room for improving the API without really breaking at some point some contrib or custom modules.

Another issue are expermiental modules in Drupal core, which are a very bad idea IMO. What is happening is we are killing Contrib. On one side we are focusing efforts into improving Core, developers' time is limited. On the other side there's very little incentive in putting too much effort into Contrib features that could be obsoleted by a new experimental core module tomorrow or may need a new upgrade to work with next Drupal 8.x.

So yes, you can keep it changing and backwards compatible forever as long as you are only using Drupal core. Not when you add contrib modules and other custom site modules into the equation, many of which rely on obscure core behaviors or array structures.

And this is because I believe Drupal core is very good but what makes Drupal great are contrib modules. And this is where innovation should happen: in Drupal contrib. That unless we have done such a poor Drupal core that new features need to be there because they cannot be implemented in contrib modules.

So far developing with Drupal 8 and a lot of contrib and custom modules, which I am doing most of the time, is an exhausting experience, trying to catch up with new Drupal 8.x releases, contrib modules working with 8.x but not with 8.y, then requiring themselves other contrib module's versions, etc.... Put aside security updates... Oops, not upgrades anymore for 8.2, you just need to upgrade *today* to 8.3... bad luck, bad day..

My proposal would be: Let's stop playing around with Drupal core and "let's make Contrib great again" ;-)

catch (not verified):

You can't rely on array structures between major releases, and you also can't do that for minor releases, nor if you use multiple contrib modules which might alter the same array since the whole point is there's an alter hook and people can alter it. However this is clearly documented in the backwards compatibility policy

If you're having contrib modules broken between minor releases, then that indicates you're either relying on APIs considered 'internal' or have run into unintentional bc breaks - have you opened issues when your contrib modules were broken?

Jose Reyero (not verified):

"You can't rely on array structures..."

Yes, and this is one of the issues that makes "backwards compatibility" not easy at all, because way too many modules depend on them.

"APIs considered 'internal'"

I would just like to know which ones are those. AFAIK we don't have such distinction anywhere and this is one of my points.

So well, it seems we basically agree smooth upgrades are not possible at all if you are running anything else than Drupal core alone?

xjm (not verified):

Ah thanks @Jose, this explains a lot. The policy documents in annoying detail what is internal vs. public, but we haven't had big bulk patches yet to put @internal on things that are @internal based on what code they are. Sounds like that is a good area to push out some better in-code documentation.

And yeah, any breaks that are problematic for you are worth tracking in and It can tell us (1) if an existing policy wasn't communicated properly, (2) if an existing policy is insufficient, or (3) if we screwed up and broke an existing policy incorrectly.

xjm (not verified):


"So well, it seems we basically agree smooth upgrades are not possible at all if you are running anything else than Drupal core alone?"

Hm I definitely don't agree with that at all; major upgrades for contrib should be no more difficult than minor upgrades. So long as (1) The contrib minimizes its dependence on internal APIs, (2) The contrib follows and corrects internal BC breaks between minors (explained in and notified in change records), and (3) The contrib updates for deprecations with the improved deprecation notices. These three things are the details of what "kept up-to-date" in the post means for contrib and custom code.

mradcliffe (not verified):

The definition of "internal APIs" is exactly my problem with the new D8 backwards-compatibility policy because it is explicitly NOT BC. In fact I say that it is the opposite of BC because it allows us to break BC.

Not being able to rely on initialize methods being stable means that contrib modules can never extend a core class, and I think that is terrible and makes the developer experience for contrib (or custom modules trying to work around core behavior) worse.

I thought about this last night again and it is a difficult problem because the only solution is to create duplicate services and code. And yet that is the only way that we can truly make core BC.

catch (not verified):

The backwards compatibility policy for minor releases is here:

Upgrading a Drupal 8 site I've been working on with 21 contrib modules and 17 custom modules between releases usually takes an hour or two at most (a bit more to test and roll out of course). In most cases this is re-applying patches to core or contrib modules for bug fixes, where those patches haven't been committed yet and sometimes need updating.

When we get reports of core changes breaking contrib modules, it's usually a few lines of test coverage (for example when the structure of the module install form changed recently), rather than significant code updates. Sometimes things go wrong, but that's more about implementation than the general framework for what and how things go in, and it's something we've only been doing for 18 months.

So it might depend what your definition of 'smooth' is.

It's worth noting that there was only 8 months of development between Drupal 4.7 and Drupal 5.0, and only a year between Drupal 5.0 and Drupal 6.0. The API breaks between these releases were much harder than between one or two Drupal 8 minor releases.

xjm (not verified):

Oh and (4) don't have dependencies on experimental modules in your contrib/custom code any more than you would have Drupal 8.0.0-alpha5 or some random specific point in a dev tarball of contrib.

Nikhil Sukul (not verified):

This is great. I think this is one the best feature which was required since inception of Drupal. I hope that the status report will capture the details for us for core upgrade and for features that will be marked as deprecated.

David Thorne (not verified):

This is huge news. I really like this approach, which is the one (or at least very similar to) Symfony took with its own 3.0 release.

One concern I do have is what this means for the supported releases model? At present the community supports version X and X-1 (At time of writing 8.2 and 7.x, shortly 8.3 and 7.x) When 9.0 comes out my understanding is we will support the last 8.x until 10.0 is released. Would this still be the case? Release cycles could easily span a lot longer timeframe than even 7.x to 8.x did given these changes, perhaps discouraging updates within the community as much as encouraging them with companies/developers who like being at the leading edge of Drupal technology.

xjm (not verified):

@Jose, thanks for your feedback.


"On the other side there's very little incentive in putting too much effort into Contrib features that could be obsoleted by a new experimental core module tomorrow or may need a new upgrade to work with next Drupal 8.x."

I've seen this concern several times, but I think it's based on a misunderstanding. What people may not be aware of is that an experimental module proposal specifically includes identifying important ecosystem contrib solutions in the area and reaching out to their maintainers before starting work, to make sure that we have their buy-in, will keep them in the loop, and support their work instead of disrupting it insofar as is possible.

We've already done this for Migrate, Workflow, Layouts, Calendar, and Media; contrib maintainers have been involved in the experimental module's introduction every time. There was some confusion between the Layouts initiative and the Panels team recently, but that's been resolved now and Panels has a forward-compatible dev branch to test out the core API and make sure it meets their needs. Core's *first* goal for these initiatives is to make sure the key ecosystem modules' needs are met by the core APIs. In other cases, certain modules are being developed in contrib specifically as a proving ground to maybe move into core.

In all cases, we evaluate whether the module really does need to be in core for some reason (expected out of the box, 50-80% usecase for Drupal, difficult or impossible to solve in contrib, API standardization needed for contrib modules to be compatible with each other, etc.) Experimental modules are certainly not intended to replace the contributed module ecosystem. We don't want to have more than about 10 unstable experimental modules at a time (and we are already setting limits on 8.4.x expectations for this reason) while contrib has thousands upon thousands of modules. Furthermore, if a contrib maintainer has concerns about an experimental module in core that impacts their module, the first step is for that maintainer to raise the concern on the core initiative plan for the experimental module. Their feedback will absolutely be taken into account.

Since experimental modules must stabilize within one year, there is also not an indefinite period of uncertainty. If there is a stable contrib solution, that stable should be used so long as the core module is experimental. If there's no stable contrib solution, then site owners have to make a choice, but in that either option still carries comparable risks, and still the contrib maintainer should have some idea what's going on with core anyway.

With regard to defining a public API and exposed data structures as API, we made a lot of advancements in that area in D8 over D7, and I've no doubt that we will continue to deprecate API with the intent of reducing API surface in the future as well. and document in extensive detail what is allowed to change between minor releases, versus what is public API and cannot change without a BC layer. The core committers follow this policy very closely, so if there's a BC break you experience that is not covered by the above, or that you find unreasonable for a minor release update, please file a specific issue about it so that the policy can be refined or the change adjusted or reverted as necessary.

Thanks! I'm sure we will make mistakes and disrupt things as we continue to adapt to a BC world, but each time we do, there's an opportunity to address it and learn from it.

chx (not verified):

How do you square this blog post with which already was committed once but only temporarily postponed to 8.4.x? "This means that modules and custom code will continue to work." -- except, of course, if they rely on Symfony. Because then they might not.

xjm (not verified):

Code directly extending Symfony should also not use their deprecated APIs; Symfony is already using the continuous upgrade path practices from this post and our approach is based on theirs. Sites with their own use of Symfony are presumably being managed with Composer, and so the site owner can also choose to handle dependencies in whatever way is needed.

In general, there are rare occasions where Drupal does need to introduce a hard BC break for a public API even in a patch or security release, to fix data integrity problems, security problems, etc. When possible, we make these changes in minor releases to minimize disruption, and there will notification in the release notes, in a change record, and even a g.d.o/core post ahead of time if we think the break needs more eyes on it. In the case of the Symfony upgrade, there will be a g.d.o/core post if there hasn't already.

Updating Symfony major versions is a security hardening because we have to be on Symfony 3 within 18 months or we lose security support. And the BC breaks for the Symfony 3 update in particular are really extremely small.

chx (not verified):

"Code directly extending Symfony should also not use their deprecated APIs"

Except nothing in that change notice is "extending" Symfony, it's just _using_ it. And Drupal core needed to be fixed, which was obviously the wrong approach because if core needed a fix then contrib / custom will need a fix too. Instead, a patch should be maintained (which Composer could apply) to keep up BC *as per Drupal policy*. This is Drupal and not Symfony.

billjents (not verified):

Funny my comment wasn't posted but I guess that makes sense. Please explain how this is any different than Wordpress? It comes off as this big revelation yet its been in place for years with other platforms. Care to explain?

nod_ (not verified):

It's great wordpress did that earlier, Drupal wasn't ready then, it is now.

I don't see why it's even a question, the two communities are similar but release at their own pace and have different priorities.

Tynan Fox (not verified):

This is great news!

I'm sure this will represent a major shift in the developer section of the Drupal community, but as one who is primarily an end-user and partially a site-builder, this is really GREAT news! Upgrading between major versions has been giving me a lot of anxiety. So many questions about when to do it, how to accomplish it, and then the eternal "what-if-I-break-things" etc.

I truly hope the core contributor/developer communities embrace this concept and more forward. I have no doubt that this ease of upgrading will be a huge selling point for end-users on the Drupal platform!

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.