2

Sorry if this is a really stupid question or if I should have been able to find it.

When it comes to module versions, how exactly does it work? Say for example the Openlayers module that has several other sub-modules, modules it integrates with, as well as modules/libraries it depends on.

Lets say open layers has the following available versions:

Reccomended: 7.x-2.0-beta5

Other Releases: 7.x-3.0-alpha0

Dev Releases: 7.x-3.x-dev 7.x-2.x-dev

Now it's time to install dependencies lets use "views module" for this case. Lets say it has these versions...

Recomended: 7.x-3.6

Other: 7.x-2.16

Dev 7.x-3.x-dev

So my question is do module updates/versions have any correlation on dependency modules? So in this situation if I install the Recommended : 7.x-2.0-beta5 of OPENLAYERS, am I suppose to install the Recommended : 7.x-3.6 of views or should I alternately install the version that has the 7.x-2.16 since both modules would then be in the same 2.x stage.

From what I've read patches are for minor releases like 7.x-2.{something) and only a major release would make a developer change to the next version 7.x-3.x. Also how does alpha, beta versions fit in with all this??? How is it that a alpha version of something is recomended over a non aplha or beta version?

The versions I've listed above are not real, but just an example. Hoverer, recently I do have issues with Openlayers and another module that required it. Both these modules had several stable versions and dev releases. Sine the sub-module is stable I'd assume it had a release that worked at one point in time with Openlayers. Is there a way to know this. Or is there a way to download using something like drush to chose dependency modules that are tested against openlayers version-whatever without problems.

Sorry for the long and horribly formatted question I hope someone can either answer or point me in the right direction to get some good documentation on this

2

Unfortunately, there are no rules. "Recommended" is just a flag set by the maintainer meaning "I think this is my most stable branch". Alpha and beta are also just labels, in the Drupal world beta often means "Works for me, but I don't want to create a full release yet."

You'd usually want to use a recommended release, if it's not too old (if it's a year old, yesterday's -dev will probably be better). Sometimes the -dev release is the most stable version of the code, if the maintainer doesn't create releases regularly.

When I have a dilemma such as yours (which version of dependency X should I use for module Y), I open an issue in the Y issue queue and ask. The maintainer knows best which code he optimized for.

  • Wow definitely wasn't expecting so many answers. Thanks! This seems like the most complete answer, although none of them were what I was hoping for which I figured... I just ran into this project drushmake.me which seemed like a step in the right direction. I'm got inspired to build upon it and put some form logic/conditions so the right/most stable dependency modules are automatically added when you pick a module. Probably impossible task for everything, but hopefully the most popular modules I can take care of. – Bryan Willis Apr 10 '13 at 7:17
0

Module versioning works like this:

DrupalMajorVersion.DrupalMinorVersion-ModuleMajor.ModuleMinor-ModuleSpecial

This means that the 7.x is your version of Drupal (i.e. any Drupal 7 version) and the 2.x-beta5 part is the version of that particular module.

With that said, you can safely install the recommended version of Views (3.6) and it should work fine with Openlayers' 2.0-beta5. (Assuming they dont explicitly tell you otherwise).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.