This issue aims at replacing the failed attempt at creating a meta-discussion about strategies and general problems in the D6 -> D7 upgrade path. This originally took place in #563106: Cannot upgrade from Drupal 6 to Drupal 7 - meta issue but that issue grew completely out of control and people started submitting patches directly in the issue.

The other issue is now closed. So I reopen this issue to specifically allow for planning high level strategies for the upgrade path. Maybe there's nothing more to do here, but please do *not* submit patches in this issue. If there's a specific issue you want to address with the upgrade path, open a new issue at tag it with the D7 upgrade path tag. You *may* reference it here, but *only* if it's relevant to the overall strategy discussion, e.g. if it's part of a multi-faceted issues that require multiple issues to be opened (a good example is #719730: drop the sequences and queue tables from D5 during the D6 -> D7 upgrade which triggered #719850: errors in update.php during bootstrap yield a blank page).

To be real clear here: do not report new issues regarding the upgrade path here: open a new issue and tag it D7 upgrade path. Major issues blocking release should be marked as critical.

Comments

anarcat’s picture

Priority: Critical » Normal

Actually, this issue is *not* critical in itself: only related issues will be critical. One less RC bug! :)

hunmonk’s picture

i'd like to suggest the following as a way to really harden the upgrade path from 6.x to 7.x:

  1. create a 6.x contrib profile, drupal_core_testing, which provides an easy way to install (for lack of a better term) a 'fully loaded' core install, complete with created node types, comments, taxonomies, users, etc. as much as possible, this profile should attempt to make use of all available features and settings in core.
  2. use the profile to troubleshoot the 6.x to 7.x upgrade routine.
  3. once the direct upgrade-related errors have been fixed, run the 7.x tests against the upgraded site.

in my mind, if we don't do something like this, we're throwing away a huge opportunity for the testing framework to benefit the stability of upgraded 6.x to 7.x installations.

going forward, a profile like this could actually be shipped with drupal core, both for use in testing the upgrade path, and as a quick way for people to get a drupal site up which demonstrates all the different things core can do. i'm guessing we'd have to shoot for 8.x to have that profile in core.

StuartJNCC’s picture

Sounds like a good idea, but I think the D6 installation should include and populate modules that have been included in D7 core - CCK, imagefield, imagecache, token, date, etc.

hunmonk’s picture

as i recall CCK's upgrade path is supposed to happen in the still-existent CCK module for 7.x. not sure about the others.

StuartJNCC’s picture

The reason I mention it is because of #799982: Updating D6 -> D7 fails if the D6 site has Date module applied. Having (some of?) these modules installed in the D6 site breaks update.inc because it attempts to create tables, fields and indexes that already exist. They exist because one or more of these modules has been installed. So I wonder what else may be in there that makes similar assumptions! For example, you see errors reported during update because the default timezone stored by the Date module in D6 is an integer (variable "date_default_timezone" has the value "i:3600"), but in D7 it is a string (the value is "s:13:Europe/London"). This is fixed by the end of the upgrade process, but maybe there are other such issues that aren't. As you suggest, it would be nice to have the tests run over the resulting site so that we can be reasonably confident that such things *HAVE* been picked up.

int’s picture

Issue tags: -beta blocker
alanburke’s picture

I haven't used it - but this
http://drupal.org/project/northdrop
could be a good install profile candidate for testing.

Robin Millette’s picture

Component: update system » ajax system

I guess we can close this, hey?

marcingy’s picture

Status: Active » Closed (fixed)