Clearly neither me nor ksenzee know what it should be, that makes it a critical bug, given we have at least one critical bug against Drupal 7 that depends on being committed to Drupal 8 first.
In case anyone's forgotten, we don't start maintaining updates between any version of Drupal and Drupal 8 except the latest dev version of Drupal 7, until Drupal 8 gets to beta or release candidate. See #760014: Stop supporting direct updates from Drupal < 6.17 for background.
This means that until then, no Drupal 7 updates will also be in Drupal 8, instead we need to increment hook_update_last_removed().
However, since bugs are fixed in Drupal 8 first, this leaves us two choices:
1. Have an 8.x patch with hook_update_last_removed(), and the 7.x patch with the update, we commit to 8.x first, so this requires the update always getting into 7.x to avoid mess. So two patches, but we need to be able to commit to Drupal 8 with some certainty there'll be no problem getting things back to 7.x (which may not always be the case for issues that aren't major.
2. Have an 8.x patch with no updates (i.e. just the fix if there is one), the 7.x patch with an update, then when the 7.x patch is committed, move the 7.x patch back to Drupal 8 to increment hook_update_last_removed(). This is three patches, and the issue has to be moved between versions at least twice.
3. Assume the patch will never be committed to 7.x, apply it to Drupal 8, backport it to Drupal 7, move the issue back to 8.x, remove the update and add hook_update_last_removed() - this is what usually happened with Drupal 6 and it was very painful, but I'm including it here anyway.
Discuss.
Comments
Comment #1
plachI think it's pretty hard to tell which is the more convenient way without knowing which is our official D8 > D7 backport process. I guess we might postpone this issue until we get a feedback on backport from Dries, which is badly needed by the way.
Comment #2
klonos...coming from #761648: Menu D6->D7 upgrade doesn't maintain node-menu configuration (f.k.a.: Menu items disappear after upgrade or manual menu entry)
Comment #3
David_Rothstein commentedDo we really need to keep hook_update_last_removed() accurate at all times in D8?
I would think there could just be one catch-all task marked critical that says "make sure hook_update_last_removed() is correct in all D8 core modules" and do that all in one go, right around the time the D7->D8 upgrade path is officially supported. That seems like it would ease the pain of having to move individual issues back and forth between D7/D8 so many times.
Comment #4
webchickI agree with David. Here's option #4:
4. Have an 8.x patch with no updates (i.e. just the fix if there is one), and a 7.x patch with the update. Create a single, postponed, critical, 8.x-dev issue tagged "Release blocker" to go through each core module and figure out what hook_last_removed() should be set to in each case.
We'd set this issue to "active" around the time alphas/betas start shipping.
git blameshould make this process relatively pain-free, albeit tedious. But far less tedious and error-prone than trying to do this on a per-issue basis.Comment #5
quicksketchYep, I also agree David and webchick. I think this is a lot of hubbub about nothing. Why is this in any way different from every Drupal release cycle before? Who's really updating from D7 to a completely dev version of D8? I think everyone would agree that's a bad idea, considering you won't be able to upgrade from D8 today to D8 two months from now (since we don't maintain inter-cycle updates).
Comment #6
catchIf you think this is hubbub about nothing, you have never read #278592: Sync 6.x extra updates with HEAD, I don't share you rose tinted view of previous release cycles.
I discussed this with webchick in irc a few days ago, but the discussion didn't make it back here. Summary is this:
- we should add a test that takes the latest 7.x database, upgrades it to 8.x, and then compares the actual schema against hook_schema().
- this means every time we make a schema change in 8.x, which should also go into 7.x, we would need to commit both the 8.x and 7.x patches at the same time - otherwise the 8.x schema will relate to an update that doesn't exist and tests for 8.x will fail. They should fail if that happens, because HEAD would actually be broken.
- if we do this then there is no danger of updates backported to 7.x sitting in the queue for months and breaking the 7.x-8.x upgrade path, that would be my only concern about syncing all the hook_update_last_removed() in one go.
Comment #7
catchRe-purposing this.
What we need:
1. Test database with every D7 module installed (but no data necessarily).
2. Run the upgrade.
3. Take the D8 schema and compare it to the actual database schema after upgrade.
There should be some code we can steal from http://drupal.org/project/schema for the comparison - I have not reviewed the internals of that module though., lyricnz reckoned it was several hundred lines of code, but I think it's worth it.
We released Drupal 7 with several schema errors on upgraded sites (found by lyricnz): http://drupal.org/project/issues/search/drupal?text=schema+mismatch+afte...
Once the test is in D8 it could be backported to D7 - although it may be too much code to add to make that worthwhile.
This, and upgrade tests in general, should block schema changes from being made to 8.x - right now we have no tests for the upgrade path at all - so keeping this as critical but changing to a task since at the moment it'll be the issue that also has to update the various export/import hooks for running tests.
Comment #8
catchPossible upgrade paths to test.
D8 tests:
7.x-latest release (we only support latest stable from when 8.x is released, test database will need updating with schema changes to D7) to 8.x.
D7 tests:
6.x-latest to 7.x
7.x-rc1 to 7.x
Started to look at schema module's code, if we strip out just the comparison functions, there is still going to be a lot there. Additionally it'll need an sqlite driver adding. However the schema comparison functions are not necessarily a bad addition to the schema API (if only for the 8.x schema module).
#1052692: New import API for major version upgrades (was migrate module) is there too, but the usefulness of this test isn't limited to core major version upgrades - it'll handle minor version schema changes, and contrib schema changes too.
Comment #9
catchDowngrading to major - we absolutely need boilerplate upgrade tests, but whoever the unlucky person is who posts the first update hook to Drupal 8 is can do those. The schema test may end up being a critical issue, but it's not right now - can just manually run schema module against an upgraded database and get the same report.
Comment #10
webchickI'm comfortable with major, but this would still be really nice to have.
Comment #11
xjmWe now have:
Given the above, is the task in this issue simply to add the schema test described in point 3 of catch's post in #7?
Also, is this blocked on #1352000: Forward-port upgrade test clean-ups from 7.x to 8.x?
Comment #12
xjmComment #13
dlu commentedMoved to database system per #2050763-16: Refine "base system" component (notes on refactoring of "base system" category here: https://docs.google.com/a/acquia.com/spreadsheet/ccc?key=0AusehVccVSq2dF...).
Comment #14
David_Rothstein commentedThis issue is about the upgrade path, so recategorizing.
Comment #15
catchNo longer an issue with #1052692: New import API for major version upgrades (was migrate module) - we're guaranteed an accurate schema on new 8.x installs, migration of config + content into that schema will either work or not.
Comment #16
catchThis would remove any need for explicit test coverage for issues like #2228217: Further optimize RouteProvider and add web test for large number of path parts, so re-opening.
Comment #27
xjmRetitling; this doesn't have anything to do with Drupal 8 specifically (nor with Drupal 7 as described in the IS). The goal is to test that the schema matches after database updates generally.
The simplest form of this might be to automatically run such a test for every
hook_update_N(). If the test fails, the schema was supposed to change, and so the test can extend the existing test to write its own test in that case. It might give us a pattern for simplifying and expanding upgrade path testing.Comment #29
quietone commentedAs pointed out in #27, this is not specific to a version of Drupal, therefor removing the 'D8 update path' tag.