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
Comment #1
anarcat CreditAttribution: anarcat commentedActually, this issue is *not* critical in itself: only related issues will be critical. One less RC bug! :)
Comment #2
hunmonk CreditAttribution: hunmonk commentedi'd like to suggest the following as a way to really harden the upgrade path from 6.x to 7.x:
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.
Comment #3
StuartJNCC CreditAttribution: StuartJNCC commentedSounds 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.
Comment #4
hunmonk CreditAttribution: hunmonk commentedas i recall CCK's upgrade path is supposed to happen in the still-existent CCK module for 7.x. not sure about the others.
Comment #5
StuartJNCC CreditAttribution: StuartJNCC commentedThe 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.
Comment #6
int CreditAttribution: int commentedComment #7
alanburke CreditAttribution: alanburke commentedI haven't used it - but this
http://drupal.org/project/northdrop
could be a good install profile candidate for testing.
Comment #8
Robin Millette CreditAttribution: Robin Millette commentedI guess we can close this, hey?
Comment #9
marcingy CreditAttribution: marcingy commented