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 ctools.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.

CommentFileSizeAuthor
#9 ctools-n2400915-9.patch6 KBdamienmckenna
#8 ctools-n2400915-8.patch6.59 KBjaperry
#5 ctools-n2400915-5.patch6.59 KBjaperry
#1 ctools-n2400915-1.patch431 bytesdamienmckenna

Comments

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Active » Needs review
StatusFileSize
new ctools-n2400915-1.patch431 bytes

This adds a line to the info file setting the version to 7.x-1.6-beta1.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Title: Hardcode the last released version in the info file » Hardcode the last released CTools version in the info file
kepford’s picture

kepford commented
Status: Needs review » Reviewed & tested by the community

Looks good. Patch applies.

mrjmd’s picture

mrjmd commented
Parent issue: » #2401915: META: Plan for CTools 7.x-1.6 release
japerry’s picture

japerry
Location KOMK
commented
Status: Reviewed & tested by the community » Needs review
Issue tags: +SprintWeekend2015
StatusFileSize
new ctools-n2400915-5.patch6.59 KB

There is a bit more I'd wanna do with this issue: In particular, the following format I think would be good for dependencies:

  • Increment the version to the next major release and append '-dev' after a release is made
  • define the version as a variable so it updates all associated ctools modules
  • put in the defined version in the info files of all associated ctools modules

Here is a patch.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Shouldn't that be?

define('CTOOLS_MODULE_VERSION', '7.x-1.6-dev');
damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Also, these should be finished sentences with periods at the end:

 * In a release, it should be 7.x-1.x, which should match what drush make will create.
 * In a dev format, it should be 7.x-1.(x+1)-dev, which will allow modules depending on new
 *   features in ctools to depend on ctools > 7.x-1.x.
japerry’s picture

japerry
Location KOMK
commented
StatusFileSize
new ctools-n2400915-8.patch6.59 KB

Updated

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
StatusFileSize
new ctools-n2400915-9.patch6 KB

I updated the comment in ctools.module, and added an example dependency line to it.

  • japerry committed 66e5196 on 7.x-1.x 
    Issue #2400915 by DamienMcKenna, japerry: Hardcode the last released...
mrjmd’s picture

mrjmd commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

OnkelTem’s picture

OnkelTem commented
Status: Closed (fixed) » Active

Sorry for I make it Active again, but I'm not sure that the goal was actually reached (if I got the idea correctly).
When I run updatedb from the command line using drush I get this warning:

Panels requires this module and version. Currently using Chaos tools version CTOOLS_MODULE_VERSION (Currently using Unresolved  [warning]
dependency Chaos tools (Version >1.5 required)

— i.e Ctools version number is not resolved, and database contains not resolved version number:

a:10:{s:4:"name";s:11:"Chaos tools";s:11:"description";s:46:"A library of helpful tools by Merlin of Chaos.";s:4:"core";s:3:"7.x";s:7:"package";s:16:"Chaos tool suite";s:7:"version";s:21:"CTOOLS_MODULE_VERSION";s:5:"files";a:5:{i:0;s:20:"includes/context.inc";i:1;s:22:"includes/css-cache.inc";i:2;s:22:"includes/math-expr.inc";i:3;s:21:"includes/stylizer.inc";i:4;s:20:"tests/css_cache.test";}s:5:"mtime";i:1426006585;s:12:"dependencies";a:0:{}s:3:"php";s:5:"5.2.4";s:9:"bootstrap";i:0;}

or unserialized:

Array
(
    [name] => Chaos tools
    [description] => A library of helpful tools by Merlin of Chaos.
    [core] => 7.x
    [package] => Chaos tool suite
    [version] => CTOOLS_MODULE_VERSION
    [files] => Array
        (
            [0] => includes/context.inc
            [1] => includes/css-cache.inc
            [2] => includes/math-expr.inc
            [3] => includes/stylizer.inc
            [4] => tests/css_cache.test
        )

    [mtime] => 1426006585
    [dependencies] => Array
        (
        )

Ideas?

UPDATE

Ok after some debugging I can say that both drush updatedb and registry-rebuild (rr) don't include module files and thus CTOOLS_MODULE_VERSION constant is not defined.

So.. it was a nice try, but the reality dictates :-(

merlinofchaos’s picture

merlinofchaos commented

So really nobody should be using a .info dependency on CTools version numbers, because CTools, being very API-centric, has its own internal API versioning that is superior.

Instead, the ctools api version should be checked in hook_requirements, allowing modules to gracefully degrade if CTools API isn't sufficient. This is also important for updates, where .info file dependencies don't necessarily cover the task.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

@merlinofchaos: So what if, for example, there's a security issue in another contributed module that only happens with older versions of the module. According to your suggestion it should just use hook_requirements to warn the site maintainer? The docblock for ctools_api_version() suggests something like the following:

 * It is recommended that every hook of your module that might use CTools or
 * might lead to a use of CTools be guarded like this:
 *
 * @code
 * if (!module_invoke('ctools', 'api_version', '1.0')) {
 *   return;
 * }
 * @endcode

But almost every module that extensively uses CTools would become partially disabled and potentially completely break the site.

This is a problem with both core's update.php and Drush.

OnkelTem’s picture

OnkelTem commented
Status: Active » Closed (fixed)

Ok, since it was me who reopened the issue (all of a sudden), I feel responsible now to resolve it back, as all "pros and cons" are pretty obvious now and we can't do anything more actually.

There is no ideal solution for the problem with D7 versioning: all git-fetched websites will suffer more or less. But there are two ways to implement "deferred" resolutions of version numbers:

1) using Git deploy (or this tiny alternative targeted to resolve only important modules);
2) using constant in .info file like it was suggested in this fix,

and both solutions allow for "Enabling" dependent modules in UI, while update process will not be that smooth, as needed hooks and files just not included. Sorry if this sounds hazy :-/