With 5.x module dependencies could be listed in .info files and would prevent modules from being used/installed if they lacked any of these dependencies. Unfortunately, this isn't fine-grained enough control sometimes, like in the case of CCK's requirements of Views. It would be nice to be able to specify specific versions of modules as dependencies.

Instead of this code (pulled from http://drupal.org/node/114774#info)

name = Forum
description = Enables threaded discussions about general topics.
dependencies[] = taxonomy
dependencies[] = comment

You would have this:

name = Forum
description = Enables threaded discussions about general topics.
dependencies[taxonomy] = all
dependencies[comment] = all

Here's what the syntax would be for all possible options:

Only specific versions
dependencies[comment] = 1.5 1.2 1.6 2.2
Up to and including this patch number (within the same major version)
dependencies[comment] = 1.5-
This patch number and above (within the same major version)
dependencies[comment] = 1.5+
Only specific branches
dependencies[comment] = 1.x

Now, there are a few problems with doing it this way:

  • How would development releases be judged as suitable? Would the datestamp of the release have to be during the timespan of all acceptable releases? What about in the case of only specific releases being supported, not a range?
  • If a module is updated to a new major version (say version 2.x) and it's still compatible with its 1.x version, would there be a way to specify this instead of requiring users to update just to get a new .info file? Maybe apply the core attribute for Drupal core to modules, also, where they can specify a core or API version...

Alos, for people wondering why only specific version of a dependency would be supported, maybe the module author wants to be sure of the quality of their release, and therefore thoroughly tests his module with its dependencies. He may not have time to thoroughly test all version of the dependency, and may therefore was to be extra cautious about the environments in which he places his module. This would prevent newbies from using the module in a potentially hazardous environment, while more advanced users willing to take a chance could just change the .info file.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Susurrus’s picture

Version: 6.x-dev » 7.x-dev
Component: install system » other
Category: feature » task

Shouldn't be in 6.x, but maybe 7.x....

Susurrus’s picture

Status: Active » Needs review

So the options for this has changed a little, but the premise is the same. The syntax should be more like the following so we end up with an array of valid versions for each module

dependencies[dep1][] = 2.x
dependencies[dep2][] = 1.x
dependencies[dep2][] = 2.x

Installation works, though some more work needs to be done on the dependency checking. I think that each branch should have it's own version requirements, so if a module specifies 1.5+

I've attached some code, but there are a few things to note:

  • There isn't an effective GUI for displaying the actual error for an unsupported module. There should be something more detailed unsupported branch and unsupported version as possible errors
  • A suggestion of what versions would be appropriate aren't displayed. This data should come from the dependency list and maybe update.module if it has cached version info.
  • There is extra code in common.inc that converts modules using the old dependency system into the new dependency listing on the fly. This should be removed eventually, but is useful for testing.
Susurrus’s picture

Attaching my patch didn't want to work, maybe this time...

NancyDru’s picture

I have mixed feelings about this. I recently has to add code for version 2 of Imagecache, but also needed to be able to support V1. So I had to code checks for versions (in this case, the API function names differ,so it wasn't a hard fix). I simply couldn't tell my users that they have only one choice of the other module. In some cases this would be okay, but do you really want to force your users into, for example, using an alpha or beta version? I don't, but my users want the option of using those versions. This suggestion won't help in that environment.

dmitrig01’s picture

Status: Needs review » Needs work

I smell tabs

catch’s picture

@Nancy. This won't be mandatory, it'll simply be an option - same as everything else in hook_requirements() currently is now. If you don't have a version requirement in your modules then this could be safely left out.

Anonymous’s picture

Subscribing

aaron’s picture

would the dependencies statement remain the same, then, if a module didn't need fine version control?

thus, would this be correct?

dependencies[] = taxonomy
dependencies[path][] = all          ;functionally identical to above
dependencies[views][] = 2.x
Wim Leers’s picture

Subscribing

Susurrus’s picture

Assigned: Unassigned » Susurrus
Status: Needs work » Needs review
FileSize
10.69 KB

So I've updated the patch, fixed a few problems, and removed the tabs. I also standardized the syntax to the following options:

dependencies[menu] = all
dependencies[aggregator][] = 6.3-
dependencies[aggregator][] = 5.5+
dependencies[devel] = 1.x

The existing syntax of an unassociated array is no longer correct and this patch adjust the .info files for a few modules as necessary. I think keeping the old syntax and then having the additional syntax of an associated array is confusing and overly complicated.

The issue with displaying a more friendly warning to the user still stands. As of now, if a module isn't the correct version it just says 'unsupported version' instead of something more specific like 'only branch 2.x is supported'. I'm not sure of the best way to display that information, though a JS popup is probably the nicest way to do it.

Also, anyone know a good way to write a test for this?

Freso’s picture

Status: Needs review » Needs work

There's excessive whitespace on several of the blank lines (including actually introducing some to includes/common.inc...). Apart from this, the code looks good from what I can tell. And I don't like the idea of a JavaScript pop-up. Too many things "pop up" these days. A drupal_set_message() would be better, though the best would be to show, directly in the listing, which versions are supported. Perhaps something like "Depends on: Path (activated), Token 1.10+/1.7-/2.x (missing)"?

Susurrus’s picture

Status: Needs work » Needs review
FileSize
9.6 KB

Went with the last suggestion in #11 to fix the missing piece of this puzzle.

Freso’s picture

Status: Needs review » Needs work

There are still a couple of lines consisting only of white-space/spaces. Also, you should use elseif, not else if.

Damien Tournoud’s picture

Well. I would like the patch better if the syntax was unchanged if a module doesn't need that functionality.

Debian has a standardized way to deal with that issue:

The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively.

For example, a list of dependencies might appear as:

     Package: mutt
     Version: 1.3.17-1
     Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

I like this optional version dependency in parenthesis.

Freso’s picture

Gentoo pretty much uses the same, just ">" instead of ">>" and "<" instead of "<<" which IMHO makes more sense, in that they're standard mathematical and programmatic operators.

I like this optional version dependency in parenthesis.

How would you do that concretely with Drupal's module listing? "Depends on: Path (activated), Token (>1.10, <1.7, 2.x) (missing)"?

Susurrus’s picture

Status: Needs work » Needs review
FileSize
10.96 KB
33.79 KB

Okay, I kept the current version specification syntax of .x, +, and -. I just like it better. Trivial change if people want to go with what's said in #15. I've attached a screenshot of what it looks like now with multiple dependencies.

The code now actually does all the .info dependency parsing in module.inc like it should (within module_rebuild_cache). It also correctly handles dependencies listed in the old format of dependencies[] = menu.

Lastly, the format for specifying dependencies is no along the lines of:

dependencies[comment] = 5.x, 6.3-
dependencies[menu] = all

Multiple versions are specified on the same line and comma-separated. This is much more module-writer-friendly I think, and extracting it into an array is trivial. Much easier to use than the old syntax.

Coding standards should now be met, but another issue should probably be raised for converting else if to elseif, as there's dozens of cases where elseif wasn't used properly.

Wim Leers’s picture

Status: Needs review » Needs work

I'm in favor of the #14 point of view, with perhaps the slight changes to it mentioned in #15. Many Drupal people are also familiar with Linux, so it'd make more sense to let our dependency system work the same as existing ones.

My initial code review (by only reading the patch, not testing it):
-It's good that the old format is now supported as well. But why isn't this feature used in the patch, then? E.g.

-dependencies[] = taxonomy
-dependencies[] = comment
+dependencies[taxonomy] = all
+dependencies[comment] = all

- This comment seems to be outdated because now you support comma separated lists of supported versions?

The various versions
+    // for a module will be an array unless it's compatible with 'all', then it
+    // will just be that string.
Susurrus’s picture

Status: Needs work » Needs review

@Wim Leers:

1) Since the module versions are exposed to site administrators, I would hesitate to say that many are familiar with linux as the majority of non-developers probably are not. It can be changed easily depending on what people think. Just note that there are only 4 possible options for version dependency: same version, same branch, less than or equal, greater than or equal.

2) The old format was updated to the new format as I think it should be if this change goes through. I look at it more like the old way is deprecated but still works more than the old way is still fully supported.

3) That comment is perfectly correct. Internally everything is converted to the new format, so if you specify dependencies[] = taxonomy or depedencies[taxonomy] = all they both end up looking like array('dependencies' => array('taxonomy' => 'all')) in the internal structure returned from module_rebuild_cache. I think there's more to that comment that that would have explained things more fully.

Setting to CNR as these are all minor issues that other people can still comment on.

Wim Leers’s picture

1) I was merely expressing my favor, that really was not the reason for setting it to CNW :)

2) Makes sense. However, now I'm actually wondering why it's a good idea to support 2 formats? Ambiguity is evil!

3) But it's no longer array notation! That's what made this comment look odd to me. This would make more sense (which also clarifies the 'all' part):
The various versions for a module are separated by commas, unless it's compatible with all versions, in which case it will just be the string 'all'.

Susurrus’s picture

2) I was only supporting one format, but then I added support for the old format in response to #14, though I guess we could get rid of the 'all' and just support the old format and the new comma-separated format, but I think always having the modules as the keys is more consistent than having it change.

3) I wasn't sure where to describe the syntax for the info files, so I have not documented it anywhere. This comment should be cleaned up through to describe better that we're taking a comma-separated string and converting it to an array or just leaving the string 'all' there if it exists. I'll reroll that tomorrow, but I'll leave it CNR because I'd like to get more eyes on this because I don't want to be doing this work if people think it's a "won't fix"...

Susurrus’s picture

FileSize
11.16 KB

Here's a reroll addressing what I said in #20. I'm not sure exactly where the 6.x, 6.1+, 6.5-, and 6.3 syntax for versions should be explained? I mentioned them in module.inc so they're at least covered somewhere besides the "Converting to 7.x" page.

I think that covers everything excluding tests (which I'm not sure we can write until you can create fake modules/info files) and the exact syntax for specifying versions (other suggestions in #14 and #15).

Dries’s picture

For me, dependencies[] = locale is easier to read than dependencies[locale] = all. I was initially confused by the 'all'.

Also, dependencies[] = locale (>= 5.0) is easier to read than dependencies[locale] = 5.3+ -- at least, it flows more natural to me.

In case we prefer + and -, I still think that dependencies[] = locale (5.3+) is easier to read than dependencies[locale] = 5.3+.

Thoughts?

Damien Tournoud’s picture

@Dries: Thank you, that was what I tried to explain in #14. I'm for one syntax only, compatible with the old one.

dmitrig01’s picture

Here is a patch that uses Dries' syntax. I agree that it's the most natural. When this gets in, I'll document it on the 7.x page

Wim Leers’s picture

I forgot to mention my preference in #19, but I agree with Damien and Dries :) I also agree with Dries' other suggestions.

dmitrig01: I think this change in system.info was unintentional?

+dependencies[] = taxonomy (6.x)

Rerolled.

dmitrig01’s picture

Yeah, it was for testing

dmitrig01’s picture

But I do prefer + and -

Anonymous’s picture

I prefer (>=5.0) syntax.

Susurrus’s picture

Assigned: Susurrus » Unassigned

I prefer the +/- syntax, but I agree that the >=/<= syntax would be more readable.

Also, my patch supported multiple versions using a comma-separated format so that dependencies[menu] = 1.x, 2.1+, 3.3-, 4.0 would be a valid dependency and could be handled correctly. As far as I can see from the most recent patches, this is no longer supported?

Also, if the format is going to be along the lines of dependencies = menu (1.3+), then I suggest parsing out the name and version information (maybe including an explode on commas re: my point above) using a preg_match versus the awkward exploding and substringing done in the latest patches. A regex of something like (\S+)\s+\(\s*[^ (]\s*\) would work better and handle deviations in whitespace better.

I'll be heading out of the country today for the next two weeks and will be unable to followup on this issue so I'm unassigning it from myself.

dmitrig01’s picture

The regex sholud be something like /^\s*([a-zA-Z0-9_]+)\s+(([0-9x]+[\.\-]?)+,?\s*)+\s*$/, but I am not the best regex writer so it probably could be simpler.

dmitrig01’s picture

The regex sholud be something like /^\s*([a-zA-Z0-9_]+)\s+(([0-9x]+[\.\-]?)+,?\s*)+\s*$/, but I am not the best regex writer so it probably could be simpler.

dmitrig01’s picture

Assigned: Unassigned » dmitrig01
lilou’s picture

NancyDru’s picture

That last one, about conflicts, really gets my interest. With it I can say "no" to Categories.

Anonymous’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

babbage’s picture

Subscribing.

dmitrig01’s picture

Assigned: dmitrig01 » Unassigned
Dave Reid’s picture

See also #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files for the proposal on adding Debian-style package terms to .info files, such as:
depends, recommends, suggests, enhances, breaks, conflicts

mitchell’s picture

Sweet! The first issue, I've seen, to explore Gentoo's Portage. I'm going to take a closer look at this when I have a chance.

Anonymous’s picture

subscribe

Paul Natsuo Kishimoto’s picture

Subscribing.

I'm really happy to see support for emulating the Debian control file syntax. It is a safe bet that a package relationship policy that has been in heavy use for twelve years is a good model.

chx’s picture

Assigned: Unassigned » chx

webchick asked me so assigning to me.

chx’s picture

Status: Needs work » Needs review
FileSize
935 bytes

This is a 100% restart of a patch. It does not yet do anything. I am submitting it here so that I can see that this does not break the graphing. Adding the actual checking is going to be quite easy, actually. This supports >, >=, <, <= and == (and even =) for version comparison. Later work might include some from above (or might not) we will see.

chx’s picture

FileSize
3.35 KB

text, CSS and test is all that's left. This works.

sun’s picture

webchick’s picture

For documentation purposes, chx asked me on IRC if we could do this just to the branch-level (for example, 6.x-1.x vs. 6.x-2.x rather than 6.x-1.4 vs. 6.x-1.6).

Although I am having trouble recalling the specific modules and versions in order to find specific issues in the issue queue, and I also try and block out this entire experience from memory whenever possible because it is incredibly traumatic ;)... I am about 98% sure that when we were writing Using Drupal, esp. with tightly-coupled modules like CCK/Views/Date/Calendar or CCK/ImageField/ImageCache/ImageAPI that we were coming across conflicts at the *point-release* level of granularity. Knowing that Date module 6.x-2.3 required Views module "6.x-2.x" wouldn't have been enough. It needed to specifically be higher than 6.x-2.1 or else everything would explode in your face.

A little less wishy-washy, I remember pretty strongly that Views module in particular was not able to really work until about Drupal 6.2 or 6.3, due to bug fixes in the theme system. Revision Moderation had a similar deal in Drupal 5... iirc there was one version of Drupal 5 that just flat-out wouldn't work. So allowing modules to also specify point-release *core* versions as dependencies would also be really useful to allow for here, if that's not already covered.

chx then asked "Well what about dev releases then?" IMO, probably the only way to deal effectively with dev releases is to check the cached update status info, which is generally knowledgable about whether 6.x-1.x-dev came before or after 6.x-1.3, based on the datestamp entry in the .info file, I presume.

But we shouldn't have to check every release against update status; only if it's a dev release version of a module.

aaron’s picture

You'd probably also need cvs_deploy in that case. What about simply making the -dev a wildcard? At this stage of the game, people using dev releases should generally already know they're on their own for the most part.

Anonymous’s picture

people using dev releases should generally already know they're on their own for the most part.

You tease us with nonsense. People use dev releases because they're impatient with waiting on a release. Most do not understand the ramifications of this release when it comes to further development of the release. I speak from the experiences of a well used module.

NancyDru’s picture

I kind of agree with Aaron. Ignorance of the law is no excuse. If you put a -dev on a live site, that's your call, but your fall too.

If adding -dev to this delays it, then don't do it. I really want this feature in D7.

@webchick, chx: No, 6.x-1.x is not adequate, IMO, at least by itself. We need 6.x-1.4 or 6.x-1.7. Contribs tend to be reluctant to change the version number because that scares adopters.

sun’s picture

Yes, both minor version dependencies (>= 1.4) as well as major version dependencies (= 1.x) are required.

However, we don't need the Drupal core compatibility of other modules in there. This is developer code, and developers know that the leading 5.x-/6.x-/7.x- refers to Drupal core compatibility. In one branch, as well as on the same site, there can only be one core version.

chx’s picture

FileSize
6.66 KB

tests still needed but the rest works. We have tons of good stuff done: views (3.x) just works. So does calendar (>=7.x-2.5). The op can be <, <=, >, >=, = (and ==). The core version is optional and then you can specify a branch or a specific version.

Edit: Forgot to mention, views (3.x) means, the op is optional and defaults to =.

dww’s picture

Status: Needs review » Needs work

I'm very excited about this patch. I keep running into cases where the ability to specify version dependencies would be a life-saver.

A few problems on a relatively quick skim of the patch. No time for a really deep review nor testing, but this is looking great.

A) The $p_* variables should be out of the loop. While we're at it, we should add a comment explaining that the '(?P<major>\d+)'; stuff is just to name the subexpression so that you get $matches['major'] when you're done.

B) It's not immediately obvious what $value is for and how it's used by _module_build_dependencies() just from reading the patch. A comment to that effect would be very helpful.

C) I don't think version_compare() is going to handle "unstable" well. Not sure if we care.

D) There's nothing in the patch (or the issue) that shows what the current expected syntax is. Hard to bikeshed^H^H^H^H^H^H^H^H comment on that without an example. ;)

Might be more, but that's a start... Keep up the great work, chx!

dww’s picture

Oh, and re: -dev releases -- SCREW 'EM! We go through a ton of trouble in update_status to support them, and it's still not perfect in all cases. There's no good answer. Screw it. If you run -dev, you're on your own.

webchick’s picture

I'm cool with the screw it approach to -dev releases, I think. :) Although at least comparing branch level versions of devs should happen.

moshe weitzman’s picture

Status: Needs work » Needs review

This patch looks good to me. I am satisfied with the syntax. It doesn't address all possible needs, but thats OK. If I knew anything about regex, I could provide a full review.

I did mention to chx that it would be nice if the .info parser and version/dependency stuff were in a couple include files that a packaging script could use. not required though.

babbage’s picture

Suggestion for -dev: as an example, for a module that is 7.x-1.x-dev, as long as there is any kind of compatibility with the branch (either 1.x or say >=1.4) then it is enabled. If it is specified that 2.x or say >=2.4, it obviously should not be as it is the 1.x branch.

Perhaps this is what is already being done. (Yet to review.) But if not, that's my suggestion.

Edit: Just re-read webchick two above and now realise that what she said anyway.

NancyDru’s picture

Personally, I think specifying -dev is false security. I don't know about others, but my modules collect patch fixes in -dev for some period of time. So a -dev release may have fixes for issues 123456, 234567, and 345678. Now issue 456789 gets fixed and some other developer needs to know that that fix is in place. Well, someone may not have the most current -dev, but they do have A -dev; they will pass the test, but the code will still fail because that admin hasn't downloaded the most current -dev.

Damien Tournoud’s picture

I can think of only one possible use of -dev releases, but that's a pretty big one: a module depending on a feature of another module that is not yet released in any stable version.

When we migrated Drupal.org to Drupal 6, for example, the Project issue module was depending on a patch to Views that was committed in -dev, but not yet in any stable release.

One way of expressing this is "views (> 6.x-2.4)"... but how the dependency manager cannot know right now to compare a -dev version to other versions. As a consequence we have two alternatives:

  • Use timestamps (ie. views (> 6.x-2.x-20090207))... that probably the easiest way,
  • Change the packaging script on d.o to package with each -dev version the information "this dev version follows the xx.yy stable version"
NancyDru’s picture

I would prefer the time stamp method as being much safer.

Anonymous’s picture

I agree with timestamps.

chx’s picture

Dev support is a subsequent patch and so is core. Period. I have now foo (>=2.2, 2.x, !=2.3) working -- dww pointed out that this was quite a valid use case when a given minor release was ~!@#$%$ up.

Said subsequent issue likely will start with the idea of changing packaging script on d.o to add -$timestamp to every dev version. But then we need to change update status too. So aanother issue.

dww’s picture

Re: "Said subsequent issue likely will start with the idea of changing packaging script on d.o to add -$timestamp to every dev version. But then we need to change update status too. So another issue."

I agree that -dev should be a separate issue. However, FYI:

; Information added by drupal.org packaging script on 2009-07-24
version = "7.x-dev"
core = "7.x"
project = "drupal"
datestamp = "1248394221"

The packaging script already encodes the datestamp of -dev in every .info file.

But I repeat: screw -dev. At least for now. ;)

chx’s picture

FileSize
10.38 KB

Comes with a very extensive, documented test.

chx’s picture

FileSize
10.23 KB

With less debug.

chx’s picture

FileSize
10.37 KB

Minor fixes, better comments.

alex_b’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
10.38 KB

Found 3 string concats D6 style. Fixed.

This is looking very solid. RTBC from my point of view.

alex_b’s picture

Status: Reviewed & tested by the community » Needs review

Setting it back to NR so that test bot picks up the patch.

chx’s picture

Status: Needs review » Reviewed & tested by the community

No need , the bot picks up the RTBC patches too.

sun’s picture

Awesome!

+  // By setting the minor version to x, branches can be matched.
+  $p_minor = '(?P<minor>\d+|x)';

What about alpha/beta/rc/unstable releases? The code doesn't look like it would handle common_test (>=2.x-beta1). I think these are equally important, because most often, a new major version introduces a new API, and during alpha/beta/rc releases, the API may be in flux. I was faced with this situation just recently.

$p_minor = '(?P<minor>\d+|x(?:-(?:alpha|beta|rc|unstable))?)';

Or similar. At least version_compare() is able to handle that -- though it will probably fail comparing 2.x to 2.0-beta2.

Dries’s picture

I think this is RTBC. However, I'd like to see a CHANGELOG.txt entry for this so if someone could re-roll with that, that would be great! :)

chx’s picture

FileSize
10.85 KB

sun, beta etc matching is a subsequent patch. Use >=2.4 for now. 2.4-beta1 is >=2.4

chx’s picture

FileSize
10.86 KB

Sorry that omitted Alex's fixes. Dries, please credit alex, dww and myself with this patch as when I started I have not used anything from before.

sun’s picture

beta etc matching is a subsequent patch. Use >=2.4 for now. 2.4-beta1 is >=2.4

I'm perfectly fine with that, if we mark that subsequent issue as critical - because, obviously, 2.4-beta1 must not be identified as being greater than 2.4. ;)

 }
 
+
+function system_test_system_info_alter(&$info, $file) {

Can we remove the duplicate line-feed here?

+  /**
+   * Attempt to enable translation module without locale enabled.
+   */
+  function testModuleVersions() {

The PHPDoc seems to be copied from elsewhere - does not match the function.

+      $graph[$start]['paths'][$end] = $v;
.....
     foreach ($module->requires as $requires => $v) {
...
+        if ($v) {
+          $requires_name .= $v['original_version'];
+          $current_version = str_replace(DRUPAL_CORE_COMPATIBILITY . '-', '', $files[$requires]->info['version']);
+          foreach ($v['versions'] as $required_version) {
...

Can we rename $v to $version_info or similar?

alex_b’s picture

FileSize
10.82 KB

#73: removed line feed, fixed comment.

$v is used all over the place. Should be a separate patch IMO.

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

dww’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
11.9 KB

Renaming $v to "$value" is like renaming $i to "$iterator". No thanks. #74 was an invalid patch file. Re-rolled #72 with the other fixes from #73, and added PHPDoc for system_test_system_info_alter(). Otherwise, identical patch, so back to RTBC.

Things we should do in follow-up issues/patches:

A) Refactor the system_modules() logic into a helper function that could be reused. I could see that being helpful in other places, and it'd be nice not to have to duplicate the (somewhat complex) logic elsewhere. Should also make it easier to write actual unit tests for that helper function.

B) Add support for version strings containing "extra" (beta, rc, etc).

C) Consider support for -dev (ultra low priority, IMHO).

That said, this is a great leap forward. Yay!

dww’s picture

A: #533584: Version dependencies: Support versions with "extra" (alpha, beta, rc, etc)
B: #533586: Version dependencies: Refactor dependency checks into sharable helper functions
C: won't fix. ;) I wouldn't mind killing -dev entirely. I'm certainly not going to go out of my way to support it here.

Paul Natsuo Kishimoto’s picture

Re: points B and C: read http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version. It seems here it would work to interpret an empty part as zero ("2.4" is "2.4-0") and ensure a numerical part sorts later (i.e. is considered newer than) a part beginning with a letter ("alpha1" or "beta1").

Thus, in proper sort order:
2.4-beta1
2.4-rc1
2.4 (as "2.4-0")
2.5+cvs20090728 (as "2.5+cvs20090728-0"), a dev release. This is seen frequently in Debian & co.
2.5-alpha1 (as "2.5+0-alpha1")
2.5 (as "2.5-0")

...etc., so that:

  • Specifying ">= 2.5" would mean no 2.5 development releases match.
  • Specifying ">= 2.5-rc" would mean only 2.5 release candidates (but not alphas or betas) match.
  • Specifying "> 2.4" would mean any 2.5 release or pre-release matches.
Paul Natsuo Kishimoto’s picture

Whoops, sorry—I'll link from the other issues.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks! Let's work on the follow-up issues now.

sun’s picture

Status: Fixed » Needs work
Issue tags: +Needs documentation
NancyDru’s picture

In addition to basic info file docs, this needs to be added to the upgrading page.

dww’s picture

sillygwailo’s picture

Assigned: chx » sillygwailo

I've started work on the documentation, see http://drupal.org/node/542202

sillygwailo’s picture

Assigned: sillygwailo » Unassigned

Relinquishing the issue, see http://drupal.org/node/542202#dependencies for updates as well as http://drupal.org/update/modules/6/7#module_version_dependencies for the note in the upgrade documentation.

NancyDru’s picture

Status: Needs work » Reviewed & tested by the community

Looks good to me. Thanks for the write ups.

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

dww’s picture

Status: Needs work » Fixed

@Richard Eriksson -- Thanks, those look great.

Status: Fixed » Closed (fixed)
Issue tags: -Needs documentation

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