Closed (fixed)
Project:
Drupal core
Version:
6.x-dev
Component:
update.module
Priority:
Critical
Category:
Task
Assigned:
Reporter:
Created:
30 Jan 2008 at 19:30 UTC
Updated:
17 Feb 2008 at 18:41 UTC
Jump to comment: Most recent file
There are a few things that should really be documented about update.module in the final 6.0 release announcement/notes, upgrade instructions, etc:
A) If you're at 5.x and running update_status, you should disable and uninstall update_status 5.x before upgrading to 6.x core. Else, your site will have some stale variables that will be more tricky to remove. I *suppose* we could add a DB update that purges these variables, basically what update_status_uninstall() is doing, but I don't know if it's considered kosher for core to be cleaning out a contrib's variables.
B) If you're deploying from CVS, you must install http://drupal.org/project/cvs_deploy or update.module won't work.
C) If you're using 5.x update status and are wondering where all those useful settings went, you should install http://drupal.org/project/update_advanced.
I'm not sure the best way to communicate all of this, so I wanted to start a discussion here, since it seems like the release is imminent. Thoughts?
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | CHANGELOG_update_contrib_pointers.patch | 907 bytes | dww |
| #5 | update_clean_5x_variables.patch | 1.27 KB | dww |
Comments
Comment #1
hass commentedsubscribe
Comment #2
moshe weitzman commentedA) Is reasonable for core to cleanup in this case.
B) Add text to admin/help/update
C) CHANGELOG.txt and a link on admin/help/update. I have no issue linking to Contrib when needed. Links are free.
Comment #3
dwwA) ok, a DB update would be easy. You could just cut and paste update_status_uninstall() from update_status 5.x-2.1.
B) That'd break the string freeze. :(
C) CHANGELOG.txt seems ok, but help text again == string breakage.
I had in mind the official release announcement, since that's immune from the string freeze. ;)
Comment #4
catchdb update sounds good - core renames contrib module tables so deleting some variables seems pretty easy. however you'll have to deal with people who already upgraded 5.x - 6.x release candidates which may or may not be an issue. Also that patch'd have to be written and RTBCed pretty quick afaik since RC3 is tantalisingly close.
Official release announcement - yeah that's good. And the http://drupal.org/upgrade page.
Comment #5
dwwComment #6
catchOK I installed D5, installed update_status, disabled it, did D6 upgrade with the patch. I didn't get this in the update.php listing, I didn't see the query run, and then when I enabled update.module the update_update_6000 was listed as not needing to be run - maybe because the module has changed it's counting it as a completely new schema version or something?
So I have a feeling this should go in system install instead.
Comment #7
catchThis was dodgy testing by me, should've done RC1 - -dev instead of 5.x - -dev. Anyway the update was run on install, and the variables gone, so it worked.
Comment #8
dwwRight, it's a whole new module, so the schema numbering starts over. There are 2 cases covered by this patch:
- People upgrading to 6.x for the first time, cleared via update_install().
- People already running 6.0-rc*, cleared via update_update_6000().
Comment #9
dww#5 is still RTBC for A). Attached patch is a proposal to address B and C via the CHANGELOG. We'll still want to mention this in the release notes, but this patch might help a little bit.
Comment #10
gábor hojtsy@dww: please go ahead and modify the bottom of http://drupal.org/drupal-6.0 with instructions for update status module users, so that part of the bug can be fixed as well for the release.
Comment #11
dwwhttp://drupal.org/node/215029/revisions/view/244620/246729
Comment #12
gábor hojtsyCommitted, thanks.
Comment #13
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.