Answers.Body: <p>It's hard to apply the Drupal model to CiviCRM because the release cycles are so very different. Drupal releases a complete overhaul every 3-5 years, with nothing but bugfixes in-between. Civi's release cycle is more frequent and incremental, with some big changes in each major release but a lot of stability too. Drupal intentionally breaks compatibility with all modules with every new major version, whereas it's not uncommon for a single copy of a CiviCRM extension to work equally well with 4.4, 4.5, 4.6 &amp; 4.7. For this sort of thing, the Drupal versioning convention would be too rigid.</p>
  
  <p>Currently each release of an extension explicitly declares which version(s) of Civi it is compatible with in its info.xml. You can see this at a glance by looking at the extension's page on CiviCRM.org - each release has one or more compatible versions listed.</p>
  
  <p>The only downside I've seen is that often times extensions continue to work fine with a new version of Civi but their info.xml hasn't been updated to show it. E.g. once 4.7 is released, the majority of 4.6-branded extensions will probably work fine, but you won't be able to automatically download them until someone manually tests, verifies, and bugs the maintainer to update their info.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-26T21:52:00.477Z
Answers.Text: "it's not uncommon for a single release of an extension to work equally well with 4.4, 4.5, 4.6 & 4.7" - what you describe is expected behaviour for Drupal modules on core releases 7.0 thru 7.xx; not sure CiviCRM is more stable than Drupal there? In the case where a Drupal module doesn't achieve this, the maintainer should use the [dependencies](https://www.drupal.org/node/542202#dependencies) field in the module's .info file, but this is only rarely required.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-26T21:56:48.347Z
Answers.Text: It's just not an apples-to-apples comparison. Drupal releases a complete overhaul every 3-5 years, with nothing but bugfixes in-between. Civi's release cycle is more incremental, with some big changes in each 4.x release but a lot of stability too.
Answers.UserDisplayName: Coleman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-26T22:01:03.817Z
Answers.Text: Yep, I agree with your answer otherwise & upvoted. Drupal's convention is too rigid for CiviCRM's release patterns. As an extension author I can't predict if a release will work with any specific future CiviCRM version, so I can't use the `.x` Joe proposes when making a release (I can use `4.4` in info.xml but not `4.x`). To me it doesn't feel CiviCRM's extension interfaces (incl not just API but tpl overrides etc) _tend to be more stable than Drupal's_, so I queried that part of the answer.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-27T00:51:40.837Z
Answers.Text: Agreed. Updated the answer with more detail from this comment thread.
Answers.UserDisplayName: Coleman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-27T03:10:23.493Z
Answers.Text: Coleman and Chris, thanks. So 4.4, say, rather than 4.x for a version number is fine by me in a naming convention. What I think I'm trying to get at is a not-rigid but better way to flag the minority of extensions that don't "probably work fine" and to know that after "someone manually tests, verifies, and bugs the maintainer to update their info", *then* an extension gets a, say, 4.7-1.0 version name. Is there a way to use Drupal's (what seems like) more-automated module testing model for Civi extensions? I've upvoted your answer and marked it as accepted.
Answers.UserDisplayName: Joe McLaughlin
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-26T21:33:59.020Z
Answers.LastActivityDate: 2015-10-27T00:51:18.203Z
Answers.LastEditDate: 2015-10-27T00:51:18.203Z
Answers.UserDisplayName: Coleman
Body: <p>I like the numeric naming conventions for Drupal modules - Drupal version number then module version number. For Drupal version 6 modules, it follows something like  6.x-2.1, for example. For Drupal version 7, something like 7.x-1.1, for example. </p>
  
  <p>For CiviCRM, naming conventions for extensions could be 4.4-1.0 and 4.7-1.0, for example.</p>
  
  <p>I think this would be <em>really</em> helpful for clarifying which extensions (should) work with which Civi versions. </p>
  
  <p>The current system is a little vague, and it's sometimes unclear which extensions should work with which Civi version. </p>
  
  <p>Also, extension version update info does not always get updated on the <a href="https://civicrm.org/extensions" rel="nofollow">Civi website extensions page</a>, but is sometimes buried in a GitHub repo issue discussion, or in a blog post elsewhere on the CiviCRM website, or issues.civicrm.org, or another website entirely.</p>
  
  <p>Thoughts?</p>
  
Tags: <extension>
Title: Can numeric version naming conventions for CiviCRM extensions use the Drupal module naming conventions?
ThreadText: # Can numeric version naming conventions for CiviCRM extensions use the Drupal module naming conventions?
  
  (Asked by: username_0 on 2015-10-26)
  
  I like the numeric naming conventions for Drupal modules - Drupal version number then module version number. For Drupal version 6 modules, it follows something like 6.x-2.1, for example. For Drupal version 7, something like 7.x-1.1, for example.
  
  For CiviCRM, naming conventions for extensions could be 4.4-1.0 and 4.7-1.0, for example.
  
  I think this would be *really* helpful for clarifying which extensions (should) work with which Civi versions.
  
  The current system is a little vague, and it's sometimes unclear which extensions should work with which Civi version.
  
  Also, extension version update info does not always get updated on the [Civi website extensions page](https://civicrm.org/extensions), but is sometimes buried in a GitHub repo issue discussion, or in a blog post elsewhere on the CiviCRM website, or issues.civicrm.org, or another website entirely.
  
  Thoughts?
  
  **Tags:** extension
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-10-26. Score: 7 | Accepted answer
  
  It's hard to apply the Drupal model to CiviCRM because the release cycles are so very different. Drupal releases a complete overhaul every 3-5 years, with nothing but bugfixes in-between. Civi's release cycle is more frequent and incremental, with some big changes in each major release but a lot of stability too. Drupal intentionally breaks compatibility with all modules with every new major version, whereas it's not uncommon for a single copy of a CiviCRM extension to work equally well with 4.4, 4.5, 4.6 & 4.7. For this sort of thing, the Drupal versioning convention would be too rigid.
  
  Currently each release of an extension explicitly declares which version(s) of Civi it is compatible with in its info.xml. You can see this at a glance by looking at the extension's page on CiviCRM.org - each release has one or more compatible versions listed.
  
  The only downside I've seen is that often times extensions continue to work fine with a new version of Civi but their info.xml hasn't been updated to show it. E.g. once 4.7 is released, the majority of 4.6-branded extensions will probably work fine, but you won't be able to automatically download them until someone manually tests, verifies, and bugs the maintainer to update their info.
  
  > **Comments:**
  > **username_2**: "it's not uncommon for a single release of an extension to work equally well with 4.4, 4.5, 4.6 & 4.7" - what you describe is expected behaviour for Drupal modules on core releases 7.0 thru 7.xx; not sure CiviCRM is more stable than Drupal there? In the case where a Drupal module doesn't achieve this, the maintainer should use the [dependencies](https://www.drupal.org/node/542202#dependencies) field in the module's .info file, but this is only rarely required.  
  > **username_1**: It's just not an apples-to-apples comparison. Drupal releases a complete overhaul every 3-5 years, with nothing but bugfixes in-between. Civi's release cycle is more incremental, with some big changes in each 4.x release but a lot of stability too.  
  > **username_2**: Yep, I agree with your answer otherwise & upvoted. Drupal's convention is too rigid for CiviCRM's release patterns. As an extension author I can't predict if a release will work with any specific future CiviCRM version, so I can't use the `.x` Joe proposes when making a release (I can use `4.4` in info.xml but not `4.x`). To me it doesn't feel CiviCRM's extension interfaces (incl not just API but tpl overrides etc) _tend to be more stable than Drupal's_, so I queried that part of the answer.  
  > **username_1**: Agreed. Updated the answer with more detail from this comment thread.  
  > **username_0**: username_1 and Chris, thanks. So 4.4, say, rather than 4.x for a version number is fine by me in a naming convention. What I think I'm trying to get at is a not-rigid but better way to flag the minority of extensions that don't "probably work fine" and to know that after "someone manually tests, verifies, and bugs the maintainer to update their info", *then* an extension gets a, say, 4.7-1.0 version name. Is there a way to use Drupal's (what seems like) more-automated module testing model for Civi extensions? I've upvoted your answer and marked it as accepted.  
  
  ---
  
  