In order to support a beta-to-beta upgrade path for Drupal 8 users sooner, this proposal recommends re-activating the http://drupal.org/project/head2head 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!
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 http://drupal.org/project/head2head 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
- 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).
- 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.
- 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)
- 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.
- 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.
- Will the people currently actively building sites on D8 actually use and (hopefully) contribute to head2head if it was up and running?
- 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.
- 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.
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.