Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The value of CTOOLS_MODULE_VERSION in the 7.x-1.14 release is set to 7.x-1.13. This is a recurring problem that started when #2400915: Hardcode the last released CTools version in the info file was committed a few years ago.
CTools hardcodes a module version into its submodule .info files, using the CTOOLS_MODULE_VERSION constant declared in ctools.module. This goes against the Drupal policy that the version number should never be set in .info because it is added to the .info file by the Drupal packager.
I sympathize with the use case presented in #2400915: Hardcode the last released CTools version in the info file as motivation for adding this constant, but the problem described there applies to ALL Drupal modules, not just CTools. The CTools-specific solution of specifying a version constant has subsequently led to this issue and other problems, without solving the broader issue of dependencies in git checkout based workflows.
Bottom line, CTOOLS_MODULE_VERSION is a very fragile construct, as evidenced by this and past problems with updating this constant, and it should be removed. Drupal now supports composer builds for D7 from specific git references or tags, and this may be used by sites to address the use-case raised by #2400915: Hardcode the last released CTools version in the info file without having to maintain this CTools-specific versioning method. Regardless, any site facing these dependency issues needs to come up with a solution that works for all modules - having a different solution for CTools just complicates the task.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2947770-6.patch | 518 bytes | joelpittet |
Comments
Comment #2
TR CreditAttribution: TR commentedNote that the patch in #2455597: Hardcoded version info breaks update report with git deploy should resolve this issue for future releases.
Comment #3
joelpittetI've committed the issue mentioned in #2. Not sure if I should close this issue? Update it to 1.15 and/or mark the constant with @deprecated.
Comment #4
TR CreditAttribution: TR commentedI don't know that we have a way to deprecate const values. Regardless, this is an internal constant and is unlikely to be used by other modules - I did a grep through the top 10,000 most-used modules and I didn't find any other usage of that constant outside of CTools itself. So it should be safe to just remove it in ctools.module.
I think that because of how you resolved #2455597: Hardcoded version info breaks update report with git deploy, this issue and #2436605: Extra version string with CTOOLS_MODULE_VERSION shows up in info files can both be closed after the constant is removed in ctools.module. If the constant doesn't exist anymore, nothing needs to be done about it for a 7.x-1.15 release.
Comment #5
joelpittetI'd rather not break a site that uses it for some (however silly) reason. It's part of the public API at this point. That's why I hinted at @deprecated.
If I were to make a 2.x branch I'd get rid of it.
Comment #6
joelpittetHere's what I had in mind.
Comment #7
joelpittetI've committed #6 . Please let me know if you have concerns with this approach.