Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.4.11
-
Fix Version/s: 4.7
-
Component/s: Drupal Integration Modules
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Contributed Code
Description
Drupal.org info files include a "project" identifier which permits checking of version information from upstream.
Drupal module info files have version in the format DRUPAL.x-MAJOR.MINOR (eg 7.x-4.4). Currently CiviCRM has version in the format 4.4 which omits the Drupal core release that the module is suited to. See https://www.drupal.org/node/1015226 for correct format.
7.x-4.4.11-rc1 is an acceptable format for Drupal (CORE.x-MAJOR.MINOR.MICRO-RELEASETAG)
7.x-4.4.11 works for major releases.
7.x-4.4 is fine too (but we use micro versions for releases so we probably want them).
The fields version and project are listed as "discouraged" on https://www.drupal.org/node/542202 as they are automatically added by the release mechanism there; this doesn't apply to CiviCRM since it doesn't ship via Drupal.org and these values aren't added automatically.
Including them in each .info file will better inform Drupal and other systems about the module origin.
Attachments
Issue Links
1.
|
Correct "project" values in CiviCRM .info files |
|
Done/Fixed | Chris Burgess |
|
Activity
Quick fix to close off this issue: https://github.com/civicrm/civicrm-drupal/pull/341
I've left off the 'minor version' as that would have to be continuously updated in the repo.
Perhaps in the future the version number could be automatically applied to the info files by CiviCRM's own packaging scripts =]
Thanks for the PR!
Fix didn't "stick" since the build scripts overwrite the change already merged here. Submitting secondary fix.
Interesting, I didn't realise they were overwritten. If we set the versions on packaging, like modules on Drupal.org, then perhaps we should take the versions out of the info files source? One less thing to update 
I'd support that. What about a placeholder like version = 7.x-4.x or version = VERSION in the git repo? Or should we add the version line in build?
I think it would make more sense to add the version line in build, but I'm happy to be convinced otherwise =]
Existing PRs have been merged - John I'm going to check in tomorrow that this has produced OK results.
Are you (or anyone) interested in pushing this ahead further? I'm happy with the change made as per https://github.com/JKingsnorth/civicrm-drupal/commit/e2daf52615135c9aa0bcda9c133d112396ffa614 - agree that removing it entirely & adding in build may be better, but current status gives git a "meaningful" number on checkout, at cost of updating it each new release.
NB: Since Drupal.org appends the version, it "works" to have the version in Git; Drupal will use the latest entry in the .info.
version = 7.x-1.x
project = mything
dependencies[] = bad_judgement
version = 7.x-1.99
OK, seems fair. We can update the versions in GIT to 4.6, 4.6, 5.0 etc. and leave the script to add any further details. Makes sense =]
fixed
Chris Burgess what's the status of this?