When working locally with a collection of modules that are all checked out via git, none of the modules will contain a version number as that string is added to the info file via the project release system. However, when many modules have started requiring specific releases of other modules it ends up causing a scenario whereby certain modules cannot be enabled.
To resolve this I propose that the panels.info file always be updated to note the last release. This will resolve the problem for local development using git checkouts, and, because the packaging system always adds its own lines to the info file which will then be used by Drupal in preference to the manually added line; there are no expected problems or regressions from this as Drupal will always use the last "version" line from the info.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | panels-n2408729-5.patch | 3.4 KB | japerry |
Comments
Comment #1
damienmckennaComment #2
damienmckennaThis sets the version to 7.x-3.4 in the info file.
Comment #3
kepford commentedLooks good. Patch applies.
Comment #4
mrjmd commentedComment #5
japerryApplied my changes similar to the ctools versioning issue. Patch here for record keeping.
Committed!
Comment #7
damienmckennaIt turns out this doesn't work correctly with Drush. When you run e.g. "drush updb" it responds:
Comment #8
damienmckennaI opened an issue for Drush about it: https://github.com/drush-ops/drush/issues/1117
Comment #10
grossmann commentedI experienced the very same issue while updating to the latest ctools (security update) and did a panels update to 3.5 too. Doing a
drush updbI got the same errors two times (one for panels and one for panel nodes) but drush did update the db anyways. Trying to update with update.php shows the same errors but won't let me continue with the update process.While disabling and re-enabling panels did not solve it, doing this with ctools solved the error.
This was, by the way, a really painful experience because of the zillion dependencies on ctools which too where disabled in the process. Re-enabling them was quite a challenge as some of them were throwing some follow up errors. Luckily I did this a dev server. I am not eager to do this on my production server.
So hopefully there is a way to get rid of the errors without re-enabling ctools?
Comment #11
damienmckenna@grossmann: Please open a new issue for this problem.
Comment #12
videographics commentedJust popping in with a clear workaround explanation (without having to patch anything) for those unable to update their databases because of this. (Searching for a resolution to the CTOOLS_MODULE_VERSION message on update.php brings you right here.)
1) Disable ctools, panels, and their myriad dependencies. (maybe painful, I know)
2) Enable ctools.
3) Enable everything else that depends on ctools.