Although it's nice to ensure people abide by the standard 6.x-1.x type of version numbering, forcing people to use that numbering system is too limiting.

For example, I need to convey compatibility with both core and my own platform, in addition to the version of the module itself which I just cannot do when forced into a single convention.

Comments

yhahn’s picture

yhahn commented
Status: Active » Postponed (maintainer needs more info)

Can you give me a little bit more information about the kind of version strings you're interested in using?

I would not recommend generating arbitrary the version strings -- FYI, the project module and update module both require a specific version format of this sort:

[core]-[major].[patch]-[extra]

e.g.

6.x-1.0-beta1

Abiding by this format is necessary for use with project, update, and drush_make.

q0rban’s picture

q0rban commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)
chipcleary’s picture

chipcleary commented
Status: Closed (won't fix) » Active

Would it make sense to add development versions to the allowed version patterns, e.g., 6.x-1.x (not just 6.x-1.0)? (When I created a module using features, I went back in by hand to make this change in the .info file it produced.)

Grayside’s picture

Grayside commented

Supporting 6.x-1.x, or 6.x-1.x-dev seems like an actual bug, since you can create releases like those on D.O.

I vote for not supporting non-standard version numbers. Most cases for using those would be custom situations anyway, so you might as well define your own "secret version" item for the .info file.

hefox’s picture

hefox commented
Status: Active » Closed (won't fix)

Closing this as looks like agreed on won't fix

kenorb’s picture

kenorb commented
Version: 6.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes

What about the version such as:

version = "7.x-1.0-alpha1+0-dev"

Which actually are set by Drupal packaging script? These are not supported either.