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.
Comment | File | Size | Author |
---|---|---|---|
#76 | 211747-76.version_dependencies.patch | 11.9 KB | dww |
#74 | version_dependencies_8.patch | 10.82 KB | alex_b |
#72 | version_dependencies.patch | 10.86 KB | chx |
#71 | version_dependencies.patch | 10.85 KB | chx |
#66 | version_dependencies_5.patch | 10.38 KB | alex_b |
Comments
Comment #1
Susurrus CreditAttribution: Susurrus commentedShouldn't be in 6.x, but maybe 7.x....
Comment #2
Susurrus CreditAttribution: Susurrus commentedSo 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
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:
Comment #3
Susurrus CreditAttribution: Susurrus commentedAttaching my patch didn't want to work, maybe this time...
Comment #4
NancyDruI 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.
Comment #5
dmitrig01 CreditAttribution: dmitrig01 commentedI smell tabs
Comment #6
catch@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.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribing
Comment #8
aaron CreditAttribution: aaron commentedwould the dependencies statement remain the same, then, if a module didn't need fine version control?
thus, would this be correct?
Comment #9
Wim LeersSubscribing
Comment #10
Susurrus CreditAttribution: Susurrus commentedSo I've updated the patch, fixed a few problems, and removed the tabs. I also standardized the syntax to the following options:
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?
Comment #11
Freso CreditAttribution: Freso commentedThere'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)"?Comment #12
Susurrus CreditAttribution: Susurrus commentedWent with the last suggestion in #11 to fix the missing piece of this puzzle.
Comment #13
Freso CreditAttribution: Freso commentedThere are still a couple of lines consisting only of white-space/spaces. Also, you should use
elseif
, notelse if
.Comment #14
Damien Tournoud CreditAttribution: Damien Tournoud commentedWell. 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:
I like this optional version dependency in parenthesis.
Comment #15
Freso CreditAttribution: Freso commentedGentoo 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.
How would you do that concretely with Drupal's module listing? "Depends on: Path (activated), Token (>1.10, <1.7, 2.x) (missing)"?
Comment #16
Susurrus CreditAttribution: Susurrus commentedOkay, 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 ofdependencies[] = menu
.Lastly, the format for specifying dependencies is no along the lines of:
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
toelseif
, as there's dozens of cases whereelseif
wasn't used properly.Comment #17
Wim LeersI'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.
- This comment seems to be outdated because now you support comma separated lists of supported versions?
Comment #18
Susurrus CreditAttribution: Susurrus commented@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
ordepedencies[taxonomy] = all
they both end up looking likearray('dependencies' => array('taxonomy' => 'all'))
in the internal structure returned frommodule_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.
Comment #19
Wim Leers1) 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'.
Comment #20
Susurrus CreditAttribution: Susurrus commented2) 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"...
Comment #21
Susurrus CreditAttribution: Susurrus commentedHere'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).
Comment #22
Dries CreditAttribution: Dries commentedFor me,
dependencies[] = locale
is easier to read thandependencies[locale] = all
. I was initially confused by the 'all'.Also,
dependencies[] = locale (>= 5.0)
is easier to read thandependencies[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 thandependencies[locale] = 5.3+
.Thoughts?
Comment #23
Damien Tournoud CreditAttribution: Damien Tournoud commented@Dries: Thank you, that was what I tried to explain in #14. I'm for one syntax only, compatible with the old one.
Comment #24
dmitrig01 CreditAttribution: dmitrig01 commentedHere 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
Comment #25
Wim LeersI 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?
Rerolled.
Comment #26
dmitrig01 CreditAttribution: dmitrig01 commentedYeah, it was for testing
Comment #27
dmitrig01 CreditAttribution: dmitrig01 commentedBut I do prefer + and -
Comment #28
Anonymous (not verified) CreditAttribution: Anonymous commentedI prefer (>=5.0) syntax.
Comment #29
Susurrus CreditAttribution: Susurrus commentedI 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.
Comment #30
dmitrig01 CreditAttribution: dmitrig01 commentedThe 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.Comment #31
dmitrig01 CreditAttribution: dmitrig01 commentedThe 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.Comment #32
dmitrig01 CreditAttribution: dmitrig01 commentedComment #33
lilou CreditAttribution: lilou commentedSee also : #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file
Comment #34
NancyDruThat last one, about conflicts, really gets my interest. With it I can say "no" to Categories.
Comment #35
Anonymous (not verified) CreditAttribution: Anonymous commentedThe last submitted patch failed testing.
Comment #36
babbage CreditAttribution: babbage commentedSubscribing.
Comment #37
dmitrig01 CreditAttribution: dmitrig01 commentedComment #38
Dave ReidSee 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
Comment #39
mitchell CreditAttribution: mitchell commentedSweet! 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.
Comment #40
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribe
Comment #41
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedSubscribing.
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.Comment #42
chx CreditAttribution: chx commentedwebchick asked me so assigning to me.
Comment #43
chx CreditAttribution: chx commentedThis 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.
Comment #44
chx CreditAttribution: chx commentedtext, CSS and test is all that's left. This works.
Comment #45
sunsubscribing
Comment #46
webchickFor 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.
Comment #47
aaron CreditAttribution: aaron commentedYou'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.
Comment #48
Anonymous (not verified) CreditAttribution: Anonymous commentedYou 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.
Comment #49
NancyDruI kind of agree with Aaron.
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.
Comment #50
sunYes, 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.
Comment #51
chx CreditAttribution: chx commentedtests 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 =.
Comment #52
dwwI'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!
Comment #53
dwwOh, 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.
Comment #54
webchickI'm cool with the screw it approach to -dev releases, I think. :) Although at least comparing branch level versions of devs should happen.
Comment #55
moshe weitzman CreditAttribution: moshe weitzman commentedThis 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.
Comment #56
babbage CreditAttribution: babbage commentedSuggestion 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.
Comment #57
NancyDruPersonally, 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.
Comment #58
Damien Tournoud CreditAttribution: Damien Tournoud commentedI 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:
views (> 6.x-2.x-20090207)
)... that probably the easiest way,Comment #59
NancyDruI would prefer the time stamp method as being much safer.
Comment #60
Anonymous (not verified) CreditAttribution: Anonymous commentedI agree with timestamps.
Comment #61
chx CreditAttribution: chx commentedDev 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.
Comment #62
dwwRe: "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:
The packaging script already encodes the datestamp of -dev in every .info file.
But I repeat: screw -dev. At least for now. ;)
Comment #63
chx CreditAttribution: chx commentedComes with a very extensive, documented test.
Comment #64
chx CreditAttribution: chx commentedWith less debug.
Comment #65
chx CreditAttribution: chx commentedMinor fixes, better comments.
Comment #66
alex_b CreditAttribution: alex_b commentedFound 3 string concats D6 style. Fixed.
This is looking very solid. RTBC from my point of view.
Comment #67
alex_b CreditAttribution: alex_b commentedSetting it back to NR so that test bot picks up the patch.
Comment #68
chx CreditAttribution: chx commentedNo need , the bot picks up the RTBC patches too.
Comment #69
sunAwesome!
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.Or similar. At least version_compare() is able to handle that -- though it will probably fail comparing
2.x
to2.0-beta2
.Comment #70
Dries CreditAttribution: Dries commentedI 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! :)
Comment #71
chx CreditAttribution: chx commentedsun, beta etc matching is a subsequent patch. Use >=2.4 for now. 2.4-beta1 is >=2.4
Comment #72
chx CreditAttribution: chx commentedSorry 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.
Comment #73
sunI'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. ;)
Can we remove the duplicate line-feed here?
The PHPDoc seems to be copied from elsewhere - does not match the function.
Can we rename
$v
to$version_info
or similar?Comment #74
alex_b CreditAttribution: alex_b commented#73: removed line feed, fixed comment.
$v is used all over the place. Should be a separate patch IMO.
Comment #76
dwwRenaming $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!
Comment #77
dwwA: #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.
Comment #78
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedRe: 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:
Comment #79
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedWhoops, sorry—I'll link from the other issues.
Comment #81
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks! Let's work on the follow-up issues now.
Comment #82
sunComment #83
NancyDruIn addition to basic info file docs, this needs to be added to the upgrading page.
Comment #84
dwwAnother related follow-up: #540952: Specify version dependencies for base themes
Comment #85
sillygwailoI've started work on the documentation, see http://drupal.org/node/542202
Comment #86
sillygwailoRelinquishing 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.
Comment #87
NancyDruLooks good to me. Thanks for the write ups.
Comment #89
dww@Richard Eriksson -- Thanks, those look great.