Regarding upgrades from 6.x, the upgrade instructions for UUID currently says:

When doing your upgrade, you must first upgrade to UUID 7.x-1.0-alpha1 in
order to not lose any data during the upgrade. The reason is because the
sub-modules responsible for the data migration between 6.x and 7.x was
removed after the release of UUID 7.x-1.0-alpha1.

Yikes! I don't see any way that drush_sup could do this automatically, save by putting a lot of uuid-specific code in the finite state machine. Is there some reason why the upgrade path was removed from the uuid module? Seems like it's still useful to a bunch of people. Maybe this has something to do with the next point...

Regarding upgrades from 7.x-1.0-alpha1 to later versions, UPGRADE.txt says:

Before upgrading, disable UUID and all UUID sub-modules... The entity specific UUID sub-module[s? sic] doesn't exist anymore.

This is a stickier problem. Drush sup will, at least, display the UPGRADE.txt before upgrading the UUID module, but pm-update will just fail without warning. Is there a way to provide a smooth upgrade path here? I don't know if there is a standard Drupal procedure for removing modules during an upgrade. Does it hurt if the code for the module that is being removed disappears before the module is disabled? I haven't tried it, but it seems like Drupal would treat this like a module with no hooks. Could the uuid module disable the removed submodule in an update hook?

Comments

dixon_’s picture

dixon_
he/him
Primary language English
Location France
commented

Thanks for the very valuable feedback on this. I think I need to think some more about this. It's really tricky when modules are dropped between releases.

Let me come back to this...

greg.1.anderson’s picture

greg.1.anderson commented
Priority: Normal » Minor

I was thinking about the major upgrade case, and decided that for most users it is not likely to be a problem. The easiest process for a major upgrade is to write your features back to the database (via drush fia), do the upgrade, and then recreate your features. In this scenario, it does not matter if your UUIDs all change, because you will never share assets between the 6.x and 7.x version of your site. I don't know if there are non-features uses of UUIDs where it is important to maintain the IDs; certainly it is most correct to maintain them, but perhaps most users would not be inconvenienced if they changed.

In a minor update, of course UUIDs should not change, but that doesn't appear to be a problem with the removed module. Whether or not the minor update issue is serious or not depends on whether or not the site breaks when this happens. I did not test, but I'm guessing that you would have had vocal complaints in this queue by now if it was causing problems for folks.

So, while I think it would be good to fix both of these items, I am thinking they are probably minor problems, pending feedback from others who are actually inconvenienced.