Opening this to discuss and track the progress towards providing a beta-to-beta upgrade path.

So far this is the only defined intermediate step between beta and RC.

I've slowly been tagging issues that either fix the upgrade path or would require an upgrade path with the D8 upgrade path tag.

Some issues block providing an upgrade path, some will require extra work once we support an upgrade path, some won't be allowed during beta once we provide an upgrade path.

Initial draft on the criteria for announcing support, and what happens to issues afterwards:

Must block a supported upgrade path between betas

  1. Critical issues in the upgrade path infrastructure itself - because it needs to actually run properly.
  2. Critical data integrity issues - because we need a starting point of data that is not broken before we try to update that data.

(There are not really 'major' versions of the above - those issues should be marked critical)

Should block a supported upgrade path between betas

Critical issue tagged with D8 upgrade path

  1. Critical issues that require an upgrade path to be written - to avoid having to write and support data migrations for critical issues we already know about.
  2. Critical issues that require additional steps to be taken after updating code (other than running update.php), this means issues with changes to the following:
    • Container rebuild.
    • Editing .htaccess / web.config
    • Editing: settings.php / services.yml
  3. Forward ports of 7.x security issue in the public issue queue: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

Could block

Major issue tagged D8 upgrade path

  1. Major bugs that require an upgrade path to be written - if we find ourselves with 20 RTBC major bug fixes on the day a beta is supposed to be released that will all need re-rolling with data migrations, then better to commit them before than after. However no specific major issue should block - if it's that important it can be bumped to critical.
  2. Updating third-party code to the latest versions, e.g. #2234277: Composer update (includes security fixes) and #2203431: [meta] Various asset (JavaScript) libraries have to be updated to a (minified) stable release prior to 8.0.0

Changes once the upgrade path is supported

Once the upgrade path is supported, several changes happen:

  1. Any issue that requires a hook_update_N() will be required to provide one once the upgrade path is supported.
  2. Any issue that requires a service container rebuild, .htaccess, web.config, settings.php or services.yml update will require a change notice + mention in the release notes, or potentially not be allowed if it's a minor change that would cause instability for existing installs.
  3. Normal or major issues that require a non-trivial hook_update_N() may get moved to 8.1.x (or 9.x if the change isn't doable in a minor version at all) once the beta-to-beta upgrade path is supported, to avoid pushing out the initial release in case they introduce bugs. This will have to be decided case by case.
  4. Additionally, any normal issue (and most major tasks) that require a hook_update_N() should be marked 'minor version target' - we'll want to minimise the number of updates that need running for 8.0.1 etc.

Open issues tagged 'D8 upgrade path':
https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

Comments

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
xjm’s picture

catch’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
catch’s picture

One thing missing from here is service definition changes that will require a container rebuild. Changes like that that aren't proper API changes I'd let in, but we need to have clear instructions on what to do when the site fatals for those cases..

catch’s picture

Two more from Alex Pott:

.htaccess / web.config

settings.php / services.yml

I'll update the issue summary.

catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

Issue summary: View changes
catch’s picture

I've updated the issue summary to include all forward ports of 7.x SA issues in the public queue (as well as security issues in upstream projects that I knew of).

A 'best effort' upgrade path also implies at least minimal effort to stop test sites getting pwned if they're publicly accessible.

I'd also suggest we ensure all libraries (PHP and js) are updated per #2234277: Composer update (includes security fixes) and #2203431: [meta] Various asset (JavaScript) libraries have to be updated to a (minified) stable release prior to 8.0.0 - that means two sets of updates, but means the second one will be smaller than if we do one massive jump.

xjm’s picture

Issue summary: View changes

Adding some markup to the summary for scannability, adding SAs to the must "should", and adding library upgrades to the "could".

xjm’s picture

Issue summary: View changes
klausi’s picture

@catch: I don't see at all how security issues would affect the D8 upgrade path? Most don't have API changes? Or do we consider throwing new exceptions early in the kernel API changes? Maybe I'm missing something, could you elaborate why?

effulgentsia’s picture

@klausi: from #11:

A 'best effort' upgrade path also implies at least minimal effort to stop test sites getting pwned if they're publicly accessible.

In other words, once we say that beta X will have an upgrade path to future betas, then some early adopters/testers will start building real or semi-real sites with them. So would be nice to have those sites not be sitting targets of publicly disclosed vulnerabilities.

klausi’s picture

I think we should not support real sites running on D8 beta. That would mean we have to develop and release D8 patches when we fix security issues internally.

Sounds more like "D8 upgrade path" is the new "critical" category, after resolving all of those people can "use" D8 in production?

Martijn Houtman’s picture

Klausi, I basically agree with your point of view, but I am currently in a situation where I need to evaluate D8 for future projects, whether or not to replace D7. An upgrade path between beta's would help a lot in this case, but I understand that not too much development time should go into this. I would much rather see it being spent on fixing the critical issues indeed.

We have a few projects coming up, which will be long-lasting projects, and I would very much like to know whether to use D7 (and risk an upgrade within a few years), or advice to go D8 within a few months. For this, I will need to evaluate quite a lot of features that we currently use in D7. We have a beta-2 install running now, and are running into a few issues. We can update to beta-3 and see if some of these things are fixed, but no working upgrade path would basically mean I will have to install it all over, right?

catch’s picture

I think we should not support real sites running on D8 beta. That would mean we have to develop and release D8 patches when we fix security issues internally.

We'd still do that publicly at least up until release candidate.

We'll still potentially catastrophically break the beta to beta upgrade path once it's in place, or have very tricky upgrade path issues, but we shouldn't knowingly have critical issues open that will require updates when we start supporting it. That's why the tag is applied to most CMI issues, but also critical issues that will require a container rebuild etc.

We released 7.0 with critical upgrade path bugs that we actually knew about beforehand but had deferred to fixing in 6.x prior to the release, then forgot about. So part of the idea here is to really get everything we know about resolved this time before saying it's OK-ish. Including certain API-changing critical issues and security issues with the criteria means the overall health of the release should be more solid than if we didn't at that point. Only about 1/4 of the current critical issues against 8.x are tagged with D8 upgrade path (including all categories here), so there'll still be plenty of nasties. Hopefully things that will kill a production site but not so much affect development.

We've already agreed to have a clean slate of security issues when 8.0.0 is released due to the 3 month 6.x support window, so I'm also hoping this may actually result in less pressure on the private security issues - since the current ones will be blocking the upgrade path when there's over 100 other public issues to fix, not the release candidate when there's 0 issues in the public queue. I'm sure we'll get security issues reported - both publicly against 8.x only, and issues that affect all branches, after we get to that clean slate, but by definition it means less issues to resolve when we're much closer to release candidate than if there's no cut off point before then.

Sounds more like "D8 upgrade path" is the new "critical" category, after resolving all of those people can "use" D8 in production?

It's more intended to be the point where you can develop a site without having to rebuild every time you update, but yes for people very aware of the risks I'd expect to see production sites as well (this happened with Drupal 7 while it was in alpha, let alone beta, with both Examiner.com and Drupal Gardens, and people working on those sites contributed to a lot of release blockers at the time since they were affecting those sites too - completely unsupported but it's very welcome to get that kind of testing).

If there was another stage, like gamma, we could call it that. We released a beta with over 100 critical issues, so there was always going to be a long window between the first beta and the first rc, the idea here is to have quite conservative criteria for a 'next stage' in between the two.

catch’s picture

We can update to beta-3 and see if some of these things are fixed, but no working upgrade path would basically mean I will have to install it all over, right?

Yes this is very likely, there's two things you can do to mitigate:

1. Export all configuration and check the YAML into version control. Even with Drupal 7 sites, for my day job we put all configuration into custom modules and run drush si with no shared database for as long a possible when building sites - saves writing hook_update_N() because you changed your mind about a field or field instance etc.. It's possible the YAML structure for some configuration will change with a new beta, but if it's in version control you can change it by hand, run drush si and see if it works again. By working this way you're actually updating custom code each beta (if you count default config as code), not data - since it's a fresh install every time anyway.

2. Try to develop the site with either no content, or be prepared to also write a module that generates some test content each time you install (entity saving should work each time for most things).

3. If your site gets broken between betas, post on the issue that broke it or open a new one to point it out. Some changes we know will break existing sites, sometimes it might be unintentional.

xjm’s picture

Issue tags: +Triaged D8 critical
jhedstrom’s picture

I've been trying to get a handle on which issues are blocking a beta-to-beta upgrade path, but the 'D8 Upgrade Path' tag seems to be a mishmash of all upgrade issues (with most of them being D7->D8). Since issues such as solidifying the views schema won't impact D7 upgrades, does it make sense to add a new tag to the ones that will impact beta-to-beta?

catch’s picture

@jhedstrom the issues that block are any critical issue tagged with D8 upgrade path.

After that, any major issue tagged D8 upgrade path will either need to have an upgrade path written for it once beta-to-beta updates are supported, or in some cases will have to be moved to 8.1.x or 9.x if the upgrade path would be too intrusive.

clemens.tolboom’s picture

Issue summary: View changes

Added links from #22 to summary

kattekrab’s picture

I've been digging about for info on how the upgrade path stuff is going. Can someone point me to an update somewhere? Or, if one doesn't exist, I'd be happy to hear a braindump and write something up for others?

clemens.tolboom’s picture

AFAIK https://www.drupal.org/project/head2head has a beta2beta sub module

catch’s picture

Yes: https://www.drupal.org/project/head2head has an upgrade path from beta 9 to beta 10.

There are four five (just tagged another one) remaining upgrade path blockers in the queue:
https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

Then 17 major issues that will require an upgrade path when they land (either in head2head, or as part of the core patch once we start supporting updates in core):

https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

catch’s picture

Status: Active » Postponed
catch’s picture

#2498625: Write tests that ensure hook_update_N is properly run is in.

#2453153: Node revisions cannot be reverted per translation we need to decide whether it is critical (and hence upgrade path blocking) or not.

And we have a couple of open critical security issues.

After that we have no official blockers to supporting an upgrade path between beta releases in core.

We should also go over https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

And decide:

1. If any of these are 'hidden critical issues' that we should get in before the upgrade path is supported.

2. If they're not, whether they will be committable between upgrade path support and 8.0.0, or should be deferred to a later minor release or 9.x.

tsvenson’s picture

Maybe this is offtopic, but since Migrate now is in core would it then be possible to include something like a .migrate as complement to the .install to handle update hooks?

I'm currently learning ruby and rails and like the way it has isolated database schema changes to be handled with their migrate feature. I find it very logical to separate storage and code changes the way it's done in Rails...

catch’s picture

@tsvenson it's off topic, but we'll probably support that with 8.x sources eventually - however 8.x sources likely won't be added until after 6.x and 7.x sources have been. Those 8.x sources would them provide the basis of the 8.x-9.x migration too as well as allowing 8-8 migrations.

tsvenson’s picture

@catch. Sounds like an excellent plan to me, using 8.x as pivot to start using migrate instead of update hooks. That way the api can probably be made more clean than have to also keep supporting both D6 and D7 ways of doing things.

marcvangend’s picture

xjm’s picture

Posted #2507899: [policy, no patch] Require hook_update_N() for Drupal 8 core patches beginning June 29, which as proposed would be the next step prior to a complete upgrade path in a later beta.

lauriii’s picture

Status: Postponed » Active

I guess this one shouldn't be postponed anymore.

catch’s picture

#2354889: Make block context faster by removing onBlock event and replace it with loading from a ContextManager is the only open issue with an upgrade path needed at the moment. If we close that then in theory we can release without adding any updates (anything else could be rolled back if it causes trouble).

#2522120: DbDumpCommand should add collation information to the generated script prevents a database dump from working properly if a table collation is changed after the dump was taken (because we ignore the actual value then create using the default on import). I'd like us to evaluate that issue as to whether it's a blocker or not.

jhedstrom’s picture

Added #2527816: Logic error in SqlContentEntityStorage::countFieldData() attempts to drop `name` column which prevents any update hooks from running if the users_field_data table is detected as having schema changes.

catch’s picture

#2528178: Provide an upgrade path for blocks context IDs #2354889 (context manager) is the upgrade path for the block changes now.

Not a blocker, but I just knocked #2261669: Slow query in NodeRevisionAccessCheck back for test coverage - that relies on the entity automatic schema updates so a good test case.

webchick’s picture

Issue tags:

At 11 (!) criticals, it's possible that the next beta is our last beta. Therefore, we should make this a "beta target" for one to try and get in before the next beta (tentatively July 22) so we could have at least one release with beta-to-beta upgrade paths.

effulgentsia’s picture

Title: [meta] Provide a beta to beta upgrade path » [meta] Provide a beta to beta/rc upgrade path

If the next beta is our last, then the only "supported" upgrade path will be beta to rc, so updating title. Of course, it's possible the next one won't be the last one, so keeping the title flexible as to that.

webchick’s picture

I'm a little confused where this issue sits now that beta13 did actually ship with an upgrade path that even seemed to actually work in my limited manual testing.

We do still have 2 (possibly 3?) outstanding upgrade path blockers, though:

* #2537928: MySQL index normalization only works on table create - RTBC, lots of +1s from real-world users. Probably will be in shortly after post-beta commit freeze is over.
* #2540416: Move update.php back to a front controller
* #2538108: Add hook_post_update_X() for data value updates to reliably run after data format updates - Overlaps with the above. Only major but people in there asking why it's not critical.

So... do we close this, because we already did it? Or do we re-title it somehow and then leave it open until those other issues are fixed? Or?

xjm’s picture

tsvenson’s picture

Issue summary: View changes
FileSize
30.98 KB

Been following the progress in this issue with great interest as it is a biggie. I have also started to play around and test a few ideas in D8 and today I had the opportunity to test how b12-b14 updating worked.

Site involved: Installed from D8b12 (some time ago) using Swedish as language setting.

Glad to report it seem to have worked just fine, no error message on screen och in dblog.

[Have reposted the below into its own issue: #2557097: The update result UI report needs clarifications

However, this report after the "update finished" is very confusing.

D8b14 update report

Particularly those three highlighted is not helpful at all, instead would probably make me quite nervous (for real site) even when the there are no failures listed below or nothing logged.

Is there no way for Drupal to verify that all known updates queued up have been performed and that the storage server (MySQL in my case) have not choked on any of them?

Right now the text tells me Drupal 8 can only guess and I can only hope that the lack of listed failures and no logged errors mean it actually worked as expected.

I would be happy to work with someone who knows the code involved here, to develop a better report than the one in the screenshot above. Feel free to ping me on IRC, I usually leave my computer logged in on #drupal-contrib and other channels.

Cottser’s picture

I'm pretty sure that message is either identical or changed very little from D7, @tsvenson I would say create a new issue to look into that. Thanks!

ianthomas_uk’s picture

xjm’s picture

@catch, @alexpott, @effulgentsia, @webchick, and I discussed the outstanding D8 upgrade path criticals today. The following two bugs with update functionality likely need to be resolved before we can consider this meta fixed:

Then the following issues related to upgrade path test coverage remain critical to fix before a release candidate:

catch’s picture

#2548725: Fix regression to menu serialization in upgrade path that causes thousands of errors in PostgreSQL (which spawned #2558247: Remove rebuildAll() and module install from UpdatePathTestBase) is still open with what looks like an actual postgres upgrade path issue (and at the moment an unrelated bug in the installer).

However unlike #2558247: Remove rebuildAll() and module install from UpdatePathTestBase what's remaining looks like an issue with the postgres driver, or at least something that's actually postgres specific and not just exposed by tests running on postgres. So I think we may actually be at a point now where we don't have (known) critical upgrade path changes to make at least on MySQL.

I just opened #2560237: UpdatePathTestBase saves the root user before updates have run as a major, although it could end up a core patch or contributed project blocker as soon as that fragile code breaks.

While it doesn't feel like sprinting across the finish line, more like stumbling across after a full marathon wearing a polyester mascot suit, we might just about be done in terms of the minimum to support an upgrade path between betas.

catch’s picture

Actually before closing, since the beta-12 to HEAD update path was completely broken (see #2558247-39: Remove rebuildAll() and module install from UpdatePathTestBase) despite passing upgrade path tests, I think we should manually test it to make sure you can actually:

- install beta12
- add a bit of content
- update to HEAD
- go to update.php and run updates

plach’s picture

Assigned: Unassigned » plach
Issue tags: +D8 Accelerate

On this

stefan.r’s picture

So...

Used this dump: https://www.drupal.org/files/issues/beta12-filled.sql_.gz

Went to update.php:

Results looked good:

No errors when logged in:

stefan.r’s picture

Hadn't seen that post @plach -- this was with the same dump as in the tests though so would be good if you could do a double check with a fresh one.

stefan.r’s picture

Issue tags: +D8 Accelerate

Don't know how that tag got removed, must have happened in the cross post

plach’s picture

I created a new installation on beta12, installed 3 languages, enabled translation for all entity types and config translation. Then I created some data for the various entity types and this was the status before the upgrade:

After checking out HEAD the theme was broken and I to clear caches to fix it:

Additionally the front page menu link was disabled:

When trying to run updates without clearing caches I needed to manually refresh the update page, otherwise it would be stuck after the first batch step. I was able to successfully complete the update this way, but I had to manually clear caches at the end of process for the site to be displayed correctly.

I restored the pre-update DB dump, cleared caches and updates run smoothly:

The end result looks correct, aside from the home page menu link that is still disabled after running the updates:

I'm attaching the beta12 DB dump in case people wants to try this by themselves.

stefan.r’s picture

@plach I imported your dump, cleared caches and went to update.php and didn't have those issues. So maybe some template issue?

I did have the disabled front page link.

As to the required cache clear after updating files to HEAD (without even having run update.php), I'm surprised that's all it took to have a semi-working site again :)

catch’s picture

@stefan_r update.php should work without a cache clear - can you try again without that step?

plach’s picture

As I said, the cache clear fixes things. The problem arises when going straight to update.php without clearing caches.

dawehner’s picture

Regarding the menu link disabling: #2548009: Overridden menu links lose parent, expanded and enabled (are disabled) status on cache clear seems to be exactly that issue.
This IS not a problem of the update path though, you should not clear caches before running update.php, well its pure randomness that you could still access the site, to be hoenst :)

The JS problem is now in a new issue: #2560521: Javascript does not work on beta 12 => HEAD update.php

plach’s picture

you should not clear caches before running update.php, well its pure randomness that you could still access the site, to be hoenst :)

I know, it was just an attempt to proceed :)

dawehner’s picture

Just tried out beta13 -> HEAD (with the JS fix applied) for a real site.

a) The update is quite slow, well we are adding more indexes and fields to the node tables for example. This is problematic / slow if you have actual content.
b) Everything works as expected

plach’s picture

Before closing this, I'd wait for the manual testing to succeed: #2560521: Javascript does not work on beta 12 => HEAD update.php is fixing the assets, but I still see the menu item disappearing, even after #2548009: Overridden menu links lose parent, expanded and enabled (are disabled) status on cache clear has been committed.

  1. I loaded the beta12 db dump I posted in #52
  2. I checked out beta12
  3. the menu page shows the link enabled
  4. I checked out HEAD and applied #2560521-45: Javascript does not work on beta 12 => HEAD update.php
  5. I run the update and I got lots of notices like the following on the selection page
      Notice: unserialize(): Error at offset 0 of 48 bytes in Drupal\Core\Menu\MenuTreeStorage->prepareLink() (line 622 of core/lib/Drupal/Core/Menu/MenuTreeStorage.php).
    
  6. When the update is over the menu link is disabled
plach’s picture

After quite some debugging I realized the beta12 DB dump was affected by #2548009: Overridden menu links lose parent, expanded and enabled (are disabled) status on cache clear and that we had a buggy static menu link override disabling the front page link ready to be applied at the first menu rebuild. In fact just clearing caches on beta12 was enough to disable the link.

This was the content of the core.menu.static_menu_link_overrides config entry before running the update process:

a:1:{s:11:"definitions";a:2:{s:18:"contact__site_page";a:5:{s:7:"enabled";b:1;s:9:"menu_name";s:6:"footer";s:6:"parent";s:0:"";s:6:"weight";i:0;s:8:"expanded";b:0;}s:20:"standard__front_page";a:5:{s:6:"weight";i:-50;s:9:"menu_name";s:4:"main";s:6:"parent";s:0:"";s:8:"expanded";b:0;s:7:"enabled";b:0;}}}

The update process just triggers a menu link rebuild, which correctly disables the menu item. The error is in the config and is introduced while working with the beta12 codebase. Hence, we should be good here :)

effulgentsia’s picture

I tried running a smoke test of update.php, not as complete as #52.

Here's what I tried, all on MAMP (so, MySql):

First, install beta-12 via web UI, Standard Profile. Create an article node. Git checkout 8.0.x. Run /update.php via browser. This worked great for me. The node tables got the expected indexes and NOT NULL constraints. The "Home" link in Main navigation remained Enabled.

Then, I started over from scratch, installed beta-12 via web UI, Standard Profile. Create an article node, with a menu link, giving it a weight of -10. Went to edit the Main navigation menu, and reordered Home to be first (so it ended up with weight=-50 and the node/1 link with weight=-49). Git checkout 8.0.x. Run /update.php via browser. This ended up fataling with a WSOD and the following in my php_error.log:

PHP Fatal error:  Class 'Doctrine\Common\Annotations\SimpleAnnotationReader' not found in /d8/core/lib/Drupal/Component/Annotation/Plugin/Discovery/AnnotatedClassDiscovery.php on line 72
effulgentsia’s picture

At @catch's suggestion, I tried the 2nd scenario from #62 again, with an apache restart prior to installing beta-12, and got a different fatal error at the end:

PHP Fatal error:  Maximum execution time of 240 seconds exceeded in /d8/core/lib/Drupal/Core/Cache/ApcuBackend.php on line 188
dawehner’s picture

At @catch's suggestion, I tried the 2nd scenario from #62 again, with an apache restart prior to installing beta-12, and got a different fatal error at the end:

What means end, is this the step where we call drupal_flush_caches?

effulgentsia’s picture

The hang in #63 was on the screen with a progress bar saying "Completed 12 of 12" and trying to redirect to the "Finished" page. During that, BareHtmlPageRenderer->renderBarePage() is called which does library discovery, which calls color_library_info_alter(), which does a config get, which because it's using the chained backend, tries to do a ApcuBackend->set().

However, I restarted my computer and tried the whole scenario again, and this time it worked. Everything completed just fine. But I was left with the "Home" link disabled, which maybe is as expected per #61.

effulgentsia’s picture

Also, I confirmed #61. Just doing this:

- Install beta-12 via web UI, Standard Profile.
- Create an article node, with a menu link, giving it a weight of -10.
- Edit the Main navigation menu, and reorder Home to be first (so it ends up with weight=-50 and the node/1 link with weight=-49).

Results in the core.menu.static_menu_link_overrides config record having enabled: false for the Home link. The link only appears to still be on the site due to the lack of a menu rebuild. So there's nothing wrong with the update.php process in this regard, only a bug with beta-12 itself, fixed recently by #2548009: Overridden menu links lose parent, expanded and enabled (are disabled) status on cache clear.

So, what's left to do/test before closing this issue?

effulgentsia’s picture

Assigned: Unassigned » catch
Status: Needs review » Reviewed & tested by the community

I also ran the same scenario as #62.2, but starting from beta-13 and again starting from beta-14. Both worked smoothly. Between that, and #59 - #61, I'm marking this RTBC, and assigning to @catch to decide on when it can be closed (e.g., whether to block on #1031122: postgres changeField() is unable to convert to bytea column type correctly and/or other issues).

catch’s picture

Assigned: catch » Unassigned

So this issue is mostly tracking which issues are necessary to cut a beta, and those boil down to 'ironing out bugs when actually updating from beta 12 to HEAD'.

#1031122: postgres changeField() is unable to convert to bytea column type correctly after the menu update patch is in is restricted to the postgres driver again and won't affect sites on postgres for that specific update handler. I think postgres and this issue don't need to be coupled, we can add an extra line to the release notes that there are several remaining postgres issues. Untagged that.

However #2561129: Composite indexes are not correctly deleted/re-created when updating a field storage definition and #2561229: Upgrade content tests fails on postgres for translated comment are not obviously postgres specific yet (and dawehner found lots of unserialize notices when testing despite us just having 'fixed' taht. So I think we should at least find out if they're driver bugs or generic upgrade path bugs before saying the update works. We've already had a couple of issues where postgres fails exposed hidden MySQL fails.

Having said all that, I don't think this issue is actually useful at the moment. We have decent test coverage now, and any critical upgrade path issues are independently critical (or actively being discussed if not), and the beta target tag works for tracking things that are beta sensitive. So I think we could close this now - even if as 'duplicate' instead of 'fixed' for a bit longer.

Leaving RTBC and unassigning.

webchick’s picture

Status: Reviewed & tested by the community » Closed (duplicate)

Since the problems uncovered in manual testing are now captured in other issues, marking this one as duplicate. Yay!