The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Currently you need to upgrade to webform 6.x-3.x *prior* to upgrading from D6 to D7, otherwise your D7 upgrade will fail. (see http://drupal.org/node/834848 for details on that). When in D6, the "available updates" page claims you are up-to-date if you have webform 6.x-2.10 installed. 6.x-3.6 is listed as an "also available" but the status is still green, so there's no indication you need to update.
http://drupal.org/projects/webform states "The 2.x version is no longer supported and will not receive any further updates. All users should update to 3.x." however that status is not reflected in the module update system (and if it was, it would save a lot of people from the trouble they're running into in http://drupal.org/node/834848 because it would be dead obvious that you need to upgrade while on D6 before continuing to D7).
Comments
Comment #1
justdave commentedAlternatively (if you don't want to freak everyone out) then 7.x-3.x should get all of the 62xx and 63xx < 6313 updates put back into it so you can upgrade from 6.x-2.x to 7.x-3.x
Comment #2
quicksketchHmm, good points. Right now by usage statistics there are still a lot more people running 2.x than 3.x though, and still (unfortunately) several Webform-dependent modules that don't work with Webform 3.x. By marking 2.x completely unsupported, it will cause an influx of users that will attempt to immediately upgrade from 2 to 3, not realizing that they will hit all the caveats in the upgrade including:
- Drastic API changes.
- Incompatibility with the current Webform-related modules they're using.
- All theming needs to be redone in the new version.
I'm not sure I want to force that upon users.
Yes that's not a bad idea, though it's not just "putting them back". D7 has different functions than D6, it's actually be more like "re-write" the ~20 some updates in the 2.x branch as and those that upgrade to 3.x.
How about instead we just make update.php refuse to update Webform in Drupal 7 if 3.x is not the last detected version? That way people wouldn't run into surprises but we won't force 50,000 users into an upgrade in Drupal 6.
Comment #3
justdave commentedThat's essentially what happens now, update.php just isn't doing a good job of informing the user (that's what http://drupal.org/node/834848 is about - getting update.php to report which module refused to update). The problem is that by the time you get this warning, it's too late. You're already on D7 at that point, you have to go back to D6 (which means restoring a backup) in order to upgrade webform and update it before going back to D7 and trying again. Anyone with an important site should have those backups to restore to of course (I did), but it's still kind of unfriendly.
Not sure what to suggest then I guess. If the 2.x->3.x updates have to be rewritten to get them back into 7.x-3.x, maybe just a single update that does the 2.x->3.x sql or something would work? I'd be willing to try to do a patch to put that in if you're scared of the work involved, but I might have a few questions about where stuff is as I go.
Comment #4
quicksketchHm, yeah you're right. We already implement the hook_last_update_removed(). In which case, I don't think this is important to address. I think this is a documentation issue at best and I won't be rewriting all the updates all over again for Drupal 7. Even if a patch were provided, I'm not interested in maintaining two entirely separate upgrade paths.
Comment #5
quicksketch