In order to support a beta-to-beta upgrade path for Drupal 8 users sooner, this proposal recommends re-activating the project in contrib and building the beta-to-beta upgrade path there in the short-term. This allows early adopters to have access to an upgrade path much earlier than core would be able to provide, and also gives us a "safe space" to test beta-to-beta upgrades prior to supporting them formally in core, without slowing down our current velocity on critical issue fixing.

Please share your thoughts, especially if you're one of the adventurous early adopters who are actively building on Drupal 8 already!

Background information

#2447573: [meta] Make sure 8.x - 8.x hook_update_N() testing is possible has quite a few things to work out regarding supporting a testable upgrade path in core. When we previously had 7-8 upgrade path testing, it was easy to take a dump of a 7.x database via drupal_get_schema(). drupal_get_schema() however is no longer fit for this purpose in 8.x (field, entity, cache etc. tables aren't in it, by design) so the infrastructure to test updates need to be rethought.

This is complex work and, in addition to the 8 other critical D8 upgrade path blockers (a number that's going down much more slowly than the number of critical issues overall), most likely means the earliest we'd be able to support a beta-to-beta upgrade path in core would be at least a month or two down the line.

In 7.x we had for quite a long time before there was an official head-to-head upgrade path. That project is dead, but we could consider reviving it. This would give us a minimally supported upgrade path from beta 8 to beta 9 (depends how quickly we can get someone started). Then early adopters can 1. start using it 2. hopefully centralize efforts around it to keep it going.

(The core committers have also discussed using D8 Accelerate fund money for this, to for example fund an upgrade just from one beta to the next one as a trial to see how bad it is - that would both give an indication of the time involved/uptake as well as give us a preview of how it might look trying to do it in core.)

If head2head is running, that takes the pressure off supporting the upgrade path in core in the short-term. Which means we don't get core bug reports for broken updates, and critical/major issues can continue to go in without the additional overhead of upgrade paths + tests for them - we'd open an issue in head2head instead.

Pros of using HEAD2HEAD before an upgrade path is supported in core

  1. We missed the window during which a working beta-to-beta upgrade path would've been most beneficial to the ecosystem, which was late last year/early this year. At this point, when we're < 50 critical issues, it feels like most early adopters have either sh*t (started developing/launching D8 sites despite the lack of upgrade path) or got off the pot (plan to wait for RC/8.0.0).
  2. head2head is the quickest possible way to provide this beta-to-beta upgrade path to the ecosystem at large. If implementers already building D8 sites banded together, and/or we funded the "kickstart" of this project through D8 Accelerate, we could have someone on this as early as next week, potentially, as opposed to mid-May+ which seems like the earliest realistic time to have a working and supported upgrade path in core itself.
  3. Helps accelerate D8's release, because once we *do* support a beta-to-beta upgrade path in core, every single patch from then on that makes changes to the data model requires a hook_update_N(), plus automated tests, plus manual testing. (While that's a positive in a way, in that it disincentives us from making non-critical changes "just because," we can't get around the fact that there'll still be overhead for necessary changes and the risk of introducing new critical bugs if updates are broken/incomplete)
  4. If we sort this out in contrib (at least at first), it allows us to push off a whole wall of pain and shenanigans of writing automated tests for the upgrade path. There's probably other unplanned for shenanigans lurking below (for example, how to handle CMI data changes, etc.) and it'd be nice to have a contrib "test bed" to work that out first before committing (pun!) to its support in core.
  5. Having the upgrade path in head2head would give us a preview of what might be required to support it in core. i.e. if beta 8 to beta 9 has 20 tricky update functions, we'll know it would have been a pain, but if it has 2 easy ones, not so bad.


  1. Will the people currently actively building sites on D8 actually use and (hopefully) contribute to head2head if it was up and running?
  2. The end of upgrade path criticals is also a natural end to other data-model affecting changes (for example, turning Taxonomy field into Entity Reference has this deadline). If we lose that, we also lose our ability to further narrow the funnel of accepted changes closer to release. This is direct trade-off vs. being able to make necessary schema changes to fix critical issues as they come up so hard to balance.
  3. By postponing the support of an upgrade path in core until later, we could very well see a surge of criticals right before RC, rather than more immediately. Going from 45->50 criticals certainly sucks, but going from 0->5 criticals and ending up with another beta or two before RC is a much bigger morale blow.

Bottom line

We could still decide to support an upgrade path at any point once the upgrade path blockers are cleared. What we can't do is undecide to support the upgrade path once we've started. As long as we can find support among those who've already developed/launched D8 sites, head2head at least theoretically allows us to not adversely impact the momentum of criticals in the short-term, provides a nice "beta test" the upgrade path, and also gives early adopters a way into D8 sooner. We'd have more time to decide when we should push that beta-to-beta upgrade path into core, a decision which needs to be carefully balanced between "quality control" and slowing down fixing of critical issues.



webchick’s picture

Note that the core committers are on board for this plan, and so we'll likely make it official in about a week if there are no heinous objections.

dawehner’s picture

I really like the idea in general.

Doing the update path in contrib has the potential to remove the overhead in core development.
We though have to keep in mind that this should not be an excuse to change more than needed, because without an upgrade path / upgrade path test, its much easier to make config changes.

Yes, if people would work on it, contrib is much more fluent to work with.
The question is, why did noone started yet, even there are multiple people out there working on sites already.
It would be great to talk with them and ask them, why they haven't considered doing it yet.

One suggestion at the end: it would be great if we could (even unrelated from this issue) tag issues which would need an upgrade path.
Change records are nice, but we don't have an API or an easy way to get all relevant ones (all config/data updates)

xjm’s picture

Issue summary: View changes
pwolanin’s picture

From the Drupal 7 cycle - this module was HEAD to HEAD, not beta to beta - so it was quite a challenge to make it work at times.

if it was constrained to be at least beta to HEAD, it would be less crazy.

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Quick note:

One suggestion at the end: it would be great if we could (even unrelated from this issue) tag issues which would need an upgrade path.

That is exactly 100% the purpose of the D8 upgrade path tag. :) So contributors should hopefully be able to look at fixed issues with that tag and see what might need an update hook. I imagine we'd add to our process filing issues for these in the HEAD2HEAD project.

xjm’s picture

Issue summary: View changes
Berdir’s picture

You might not have thought of it, but as a matter of fact, we already have a partially supported upgrade path in core. The generic entity update system.

It's failing very, very hard from beta6 to beta7 without some hacks, due to weird serialization bugs, but once I worked around those, it actually did things, like adding new indexes, creating new fields and so on.

So far, I only had to write a small update because block cache contexts were renamed and a bigger one to rename user-path: to internal:, just created an issue for that in HEAD2HEAD: #2456005: Support rename from user-path: to internal:/ link fields (beta6 to 7) .

With that, I got a beta6 site running on beta7 code (at least some pages), will continue with more testing and fixing stuff tomorrow.

cjoy’s picture

it disincentives us from making non-critical changes "just because,"

I would have thought that, at this point in time, no further (dis)incentive would be required on that front.
So I don't understand is how this would help speed up the resolution of issues in core that block the upgrade path.
As someone who is sitting on the fence, waiting for a beta release that can be transitioned into a stable release, I'm not sure I would trust an upgrade path that is shoved off to contrib, while the data model of core remains in flux. Would it not be better to focus energy and money on resolving those criticals?

xjm’s picture

As someone who is sitting on the fence, waiting for a beta release that can be transitioned into a stable release, I'm not sure I would trust an upgrade path that is shoved off to contrib, while the data model of core remains in flux. Would it not be better to focus energy and money on resolving those criticals?

For clarification, we are already focusing energy and money on resolving those criticals. Numerous of the awarded D8 accelerate grants are focused on them, as are other proposals underway. It's also a main focus of work for @webchick, @effulgentsia, @Gábor Hojsty, @tim.plunkett, @Wim Leers, and myself. Only 9 of these upgrade path blocker issues remain of over 80 so far. This proposal will not change that focus, because a stable data model and secure D8 are still an important place to front-load critical work.

It's not that progress on these issues is slow; it's that new critical issues are identified that have security or upgrade path impacts as we fix older ones. There is high turnover in the critical queue generally and in the upgrade path blocker list as well.

All such new issues take twice as long to fix in the future once we must support a robust upgrade path in core. So it's worthwhile to work out the rough patches now, before adding that requirement.

Edit: I should have mentioned, @cjoy, thanks for pointing out that you are one of the folks waiting for an upgrade path and that this wouldn't help in your case. That's important information too. Just needed to clarify that the upgrade path blockers are still a top priority regardless. :)

xjm’s picture

Or, put another way, the goal of this proposal is not to replace the supported beta-to-beta/rc upgrade path in core or work on it. Rather, it's to get a head(2HEAD) start on it, and accomplish some of the goal that the upgrade path milestone was originally intended to (by enabling more support for and feedback from the bleeding-edge early adopters).

marcingy’s picture

If we are going to start this and I am plus 1 on the idea, we really need to close out issues from 4 years ago on the head2head project. We are doing weekly head updates (this is not on main site but a new build) so would more than happy to help support an update path. But also I like the idea of getting this into core as soon as possible.

webchick’s picture

I definitely appreciate cjoy's perspective, and appreciate you sharing it. I'm sure it's a similar perspective held by others who might not be so bold as to leave a comment about it. :)

Where we're coming from with this proposal is despite an extremely large push by the folks xjm mentioned in #11, along with many others, and lots and lots of fixed upgrade path blocking issues (looks like 4-5 a week, on average), we are still (currently) finding almost as many of these critical upgrade path issues as we're solving each week, for various reasons. For example, when new SAs were announced for Drupal 7 yesterday, that resulted in 2 new upgrade path blocker issues... they were fixed quickly, but still caused the total to jump. The number of total unsolved upgrade path blockers has hovered around 9-12 for about several months in a row now (though it's now the lowest it's been in awhile, hooray!).

If current trends continue (and as xjm mentions, we really are trying every possible method of accelerating this we have at our disposal currently), it's realistically going to take a couple of months before we get that count down to zero and it stays down, and it would only be at that point we could entertain the idea of supporting the "official" upgrade path in core. That's with or without this proposal.

The advantage of this proposal is that we wouldn't have to wait a couple of months to provide that upgrade infrastructure to early D8 adopters; we could basically start today (ok, maybe next week ;)). And by the time we get on the other side of those upgrade path blockers in core, we'd now have a couple of months of experience in how writing these goes in the "real world," making the decision of when exactly to support the beta-to-beta upgrade path "officially" a much more well-grounded decision. (As the summary mentions, there's a trade-off here too, in that once we support an upgrade path, it makes any of the other 40+ critical issues that touch a schema somewhere much more difficult to close.)

Not sure; does that help assuage your concerns at all? The bottom line is this isn't a deviation from the current plan of killing those upgrade path blockers with fire wherever we find them. It's simply an intention of getting the benefit of an upgrade path to D8 early adopters as soon as possible.

cjoy’s picture

@xjm @webchick

Thank you both for the explanation and clarification of the pro arguments here.

If there really needs to be an upgrade path ASAP, I would follow your reasoning as to why it should not go into core until things are more stable.

Using contrib as a gauge to see when the PITA rating of supporting an upgrade path has reached a bearable level makes sense, too.

However, I still do not fully understand how this initiative would speed up a D8 RC (#3). Providing an upgrade path in core would slow it down, sure, but while there are unresolved upgrade path blockers, this is not an option anyway, right? At this point I would think it is a question of having no upgrade path at all or having one in contrib.

That said, I just want to quickly clarify that I am aware of and highly value the many efforts put into closing those upgrade path blockers. Apologies if my above comment made it sound otherwise and thank you for the great work on those hard issues!

clemens.tolboom’s picture

Title: [policy, no patch] Re-activate the head2head project and use it for beta-to-beta upgrades in the short-term » [policy, no patch] Re-activate the head2head project and use it for beta2beta upgrades in the short-term

We started to develop a start up headless Drupal @ beta3 site but decided to stop @ beta7 due to rebuilding the site over and over again on every new much needed beta release draining too much time. We switched back to D7 which is a bliss regarding features, cors, restws modules :-/

For me this decision meant due to balance of time/money not much time left for D8 development. If funded properly I'd love to participate.

googletorp’s picture

Title: [policy, no patch] Re-activate the head2head project and use it for beta-to-beta upgrades in the short-term » [policy, no patch] Re-activate the head2head project and use it for beta2beta upgrades in the short-term

I'm working on a new Drupal site which we decided to make in Drupal 8. I think we started around beta 4-5 and have upgraded core a few times, currently stuck somewhere between beta 6 and beta 7.

I love the idea of having a beta2beta program in contrib. In my experience, doing Drupal core development, is very slow and requires a lot of time and waiting time, to close issues. To be honest, I have a hard time motivating myself for Core contribution because it usually takes months to make a simple bugfix.

Please, don't get me wrong. I'm not saying the way core development is done is bad, just that it doesn't really goes well with me, as I only occasionally can invest time.

I would like this to start in contrib, as it would attract people like me. Also I'm close to point in the development, where is will be required to be able to update Drupal (and provide valuable feedback data).

eiriksm’s picture

As someone who is sitting on the fence, waiting for a beta release that can be transitioned into a stable release, I'm not sure I would trust an upgrade path that is shoved off to contrib, while the data model of core remains in flux. Would it not be better to focus energy and money on resolving those criticals?

Just chiming in my 2 cents. I agree with this. And as someone who is maintaining a small handful of (granted, very small) Drupal 8 sites, I do complete re-installs between upgrades with my own migrate path.

I would still do that if the upgrade path were a contrib project. But if an upgrade path was in core, I would go for that.

That being said, I understand where the idea is coming from. But still, someone would have to work on these issues, regardless if it was in core or contrib, no?

Of course, this is purely practical points of view. As somone mentioned, it might get more work done if in contrib, and if so, then it sounds like a great plan. Work-wise, that is.

Edit: Not to come off as negative (just felt like giving an opinion of "early adopters"), I want to state that I think you people doing these tasks are doing an amazing job. I know these issues are (as xjm explained) hard and constantly popping up. So I really do appreciate the work being done. Also, I want to state, that if the path forward ends up in contrib first, I would try my best to test-drive the upgrade paths and contribute issues or code to the project (given time)

alanburke’s picture

Much like others who were early adopters, our resources to try and keep upgrading with betas has exhausted.
We're waiting for a core-supported upgrade path before picking up D8 projects again.

And to echo the last comment - we're appreciative of the work undertaken and understand the effort involved.


catch’s picture

However, I still do not fully understand how this initiative would speed up a D8 RC (#3). Providing an upgrade path in core would slow it down, sure, but while there are unresolved upgrade path blockers, this is not an option anyway, right?

The (short) definition of an upgrade blocker is any one of the following:

1. Makes it impossible to support an upgrade path at all e.g. #2447573: [meta] Make sure 8.x - 8.x hook_update_N() testing is possible

2. Critical issue that requires an upgrade path to be written e.g. #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency

3. Publicly disclosed security issue e.g. #2418119: REST user updates bypass tightened user account change validation

In practice only the first category of issues absolutely prevents us saying the upgrade path is 'supported'. However if we start doing so, then the second category means that the critical fix rate would slow for those issues as well as bugs in those upgrade paths potentially becoming new critical issues. And the third category means that while we'd be encouraging people to develop non-throwaway sites on 8.x while there's open public security issues that could result in those sites getting destroyed.

So head2head running means that we can hopefully find issues in the first category quicker than we would otherwise. For example I only opened the upgrade path testing issue after talking to xjm about when it might be possible to support the upgrade path in core, thought about what we'd need to do it practically, then realised all the infrastructure is outdated now. Even thinking about supporting the upgrade path results in new upgrade path blockers ;)

It would not have been impossible for us to get to 0 upgrade path blockers, make an announcement, then realise we couldn't write tests for any of the updates we'd started requiring. head2head running for a beta release or three should help to flush those out.

Also people like yourself who are waiting for beta to beta updates before digging in on an 8.x project, if you decided the head2head project was enough to get started, you might then find previously undiscovered critical bugs in 8.0.0 that haven't been found previously. Real site building tends to uncover issues that the test suite doesn't. The earlier those kind of bugs are found, the less there are to find when we get to the final beta and early release candidate stage when many more people will be testing. Those issues also might be in the 1st, 2nd or 3rd categories of upgrade path blockers, so in turn mean less to do in core once we support it (because we'd fix them beforehand).

@berdir while the entity/field system can update itself, it's also not currently possible to export a previous version of an entity/field schema then update it to the current one with the core testing infrastructure. So even if we don't have to write update hooks, we'd need to be able to test the schema updates themselves with and without data. Realising this (and that we've never done a CMI update in core either) made me think head2head would be a good interim step.

David_Rothstein’s picture

So can the part of this proposal that's relevant for core basically be summarized as "even when all the known upgrade path blockers are fixed, reevaluate then whether it makes sense to start actually supporting the upgrade path vs. continuing to wait longer"? If so, it sounds good.

For the rest, don't see why a core issue is really needed to propose reviving a contrib project :) As one of the "maintainers" of head2head (oh it brings back memories) I'd certainly be willing to give out commit access freely, like candy to children. (Or maybe like cocaine to elephants.) I assume others who have that permission would too.

David_Rothstein’s picture

If we are going to start this and I am plus 1 on the idea, we really need to close out issues from 4 years ago on the head2head project.

I went ahead and closed all the old issues now.

catch’s picture

@David it takes some of the pressure off supporting the upgrade path in core if head2head is supported, although of course we could still decide to do so more or less straightaway once we reach zero blockers.

Otherwise I think it's a core issue for discoverability rather than applicability.

scor’s picture

Definitely in favor of this proposal, and like others have said, great work on all fronts from people pushing for this idea. I will definitely use such upgrade path for currently running on beta4. To give a bit of background, initially launched on alpha4, then manually upgraded to beta4 by basically doing a full site rebuild and using the migrate module to migrate the nodes and users. I know I will have to go through the same again next time I want to upgrade, but I promised myself to only do it when there is a beta or RC with an upgrade path available. Needless to say I'm excited about this proposal!

amateescu’s picture

Maybe it's useful for everyone following/discussing here to know that I already started this effort in #2456419: Upgrade to Drupal 8 and provide a beta2beta submodule :)

catch’s picture

Status: Active » Reviewed & tested by the community

Bumping this to RTBC. Given beta8 was just released moments ago, beta8 to beta9 support in head2head would be a good starting point I think (or beta7 to beta8 even).

webchick’s picture

The one thing I'd love to sort out is maintenance of head2head. amateescu is getting a jump-start, but what's the process of getting him added as a committer?

I kind of want to change the node author to "Drupal" and open up commit access to anyone who submits a patch, basically. :) But curious of David's thoughts.

David_Rothstein’s picture

My thoughts are still this:

As one of the "maintainers" of head2head (oh it brings back memories) I'd certainly be willing to give out commit access freely, like candy to children. (Or maybe like cocaine to elephants.)


So I'm happy to give @amateescu commit access if he wants it! @amateescu - do you want commit access?

@catch is technically the real project owner, not me, but in Drupal 7 we effectively did just give commit access to anyone who was working on the module at all. (Having the project owned by "Drupal" seems a little odd to me, but don't really care either.)

webchick’s picture

Assigned: Unassigned » Dries

Ok, had a short IRC convo and now:

- amateescu has commit access on the project, so someone from the active D8 contributor pool is a maintainer (thanks, amateescu!)
- The process for how other people can get commit access as well is documented on the project page.
- Also updated the project page for the current reality:

Now, +1 to RTBC. ;) Since this is a policy change, probably would be good for Dries to formally do the sign-off, but since he already agreed to this, I think we can go ahead and get started without that.

effulgentsia’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs issue summary update

I think before asking Dries to make a decision here, we need to be clearer on what the scope of this issue is. Now that the contrib project is active, what's the proposed policy with respect to core? For example:

  1. Are we adding a core gate that from now on (or from date X on), any data-affecting patch committed to core must get a head2head issue filed prior to RTBC/commit of the core issue?
  2. For a non-critical (e.g., Major) priority data-affecting issue, do we also want to require that someone volunteer to work on that head2head issue as a condition of committing the core patch?
  3. Is there any policy change being made here with respect to when a beta-to-beta upgrade path move into core? For example, is it when the critical D8 upgrade path queue reaches 0, or is it now some other criteria?
Beanjammin’s picture

I'm really excited to see this happening. I dove into D7 at the alpha stage thanks to head2head and have been watching the D8 upgrade path issue queue as a sign for when its time to jump into D8 as opposed to just tinkering around the edges.

FWIW I have looked through the D8 upgrade path issue queue a few times and can appreciate why it's shrinking so slowly. There's very little in there that I have managed to wrap my head around, nevermind contribute to solving..

catch’s picture

#1 Could go either way on this. We should definitely be careful about the D8 upgrade path tag so things are easy to find. I don't think issues should get opened at RTBC stage - that could lead to unnecessary work being done in head2head so needs to be on/post commit.

#2 I think this depends on the issue. #2261669: Slow query in NodeRevisionAccessCheck or #2457653: langcode is both used as a file language code and a site language code I wouldn't want to require a volunteer for issues like that. It needs fixing either way in core (i.e. while not release blockers we wouldn't want to punt those issues to Drupal 9 either). Also if there was never an upgrade path it's not that onerous to fix. The taxonomy/entity ref change it's great to have the upgrade path for that (although can't see any more issues like that coming through). Something like a cosmetic-ish rename probably too, although we shouldn't be committing many/any of those anyway.

#3 I don't think there's an explicit change, but I do personally think we should treat this similar to RC phase where we look at the recent incoming issues more than just hitting zero.

webchick’s picture

Status: Needs work » Fixed
Issue tags: -revisit before release candidate

This ended up happening: and core now requires hook_update_N() so I don't see any reason to keep this open nor to revisit it at this point.

xjm’s picture

Assigned: Dries » Unassigned
Issue tags: -Needs issue summary update

Nor does it need to be Dries-assigned. :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.