I feel rather uncomfortable about the current approach of managing module version data in *.info files, namely that the drupal.org packaging script adds that.

It is often much more convenient to install a module with git, rather than as a tarball, especially when there is a chance that I want to make local modifications to the module. However, at the moment, what I get from a tarball and a git clone differs: the *.info file is changed by the drupal.org packaging script.

The fact that the version data is missing in the git repository has lead to two workarounds, but I find both of which somewhat clumsy:

a) The "git_deploy" module tries to infer the missing version data from .git metadata. That either requires a git implementation in php (not mature), or php access to the git binaries (not secure).

b) The "drush dl" command now has options "--package-handler=git_drupalorg --gitinfofile". They perform a git clone, followed by adding the desired version data to the *.info file. While more practical than "git_deploy", it still creates a local change in a working directory that hasn't actually been edited.

It clearly would be much cleaner if the drupal.org packaging script did not modify the tarball at all (and in fact used the "git archive" command to produce the tarballs.)

Is there no other practical solution to guarantee that *.info files contain accurate version data?

For example:

1) A git hook script on drupal.org could allow the addition of release tags only after checking that the *.info file version information is correct.

2) A drupal.org robot could automatically follow-up any release that has incorrect version information with a correction commit in which the *.info file is fixed.

Either approach would render the "git_deploy" module and the drush project manager option "--gitinfofile" (and associated headaches) obsolete.

Comments

halstead’s picture

halstead CreditAttribution: halstead commented

It would be nice to fix at this level but it's not easy. My concerns,

1) A git hook script on drupal.org could allow the addition of release tags only after checking that the *.info file version information is correct.

We do not want more barriers to pushing code. This approach would cause unwanted frustration.

2) A drupal.org robot could automatically follow-up any release that has incorrect version information with a correction commit in which the *.info file is fixed.

This is possible but as a result release tags wouldn't actually point to the release. It also requires the packaging system to write to git repositories which some project owners object to.

mkuhn’s picture

mkuhn CreditAttribution: mkuhn commented

OK, so here is another, much simpler suggestion:

The drupal.org packaging script (and "drush dl --package-handler=git_drupalorg") could *add* a new file with the required version information, rather than appending lines to a *.info file that exists already in the repository.

This way, that added version-information will not be flagged up and tracked by git as a local modification, because the file is never added to the repository.

Just keep information edited by humans and information added automatically by packaging scripts in separate files, and the problem is gone.

a.ross’s picture

a.ross CreditAttribution: a.ross commented

That's the solution I was thinking of as well, but that would require changes to Drupal core to read from the version file in stead of the info file. Additionally, drupal.org would need to support both adding version info to the info file (for old and current versions of core) and the version file (for new incarnations of core that support it).
Lastly, project maintainers would be more or less forced to add the version file in their .gitignore, which may also be undesirable. If it's not in the .gitignore, then the version file is added to patches a developer may create, possibly causing other issues as well.

As it stands, it would make sense to add an issue to Drupal core pertaining to this issue. Any other ideas?

It's interesting to note that a number of issues regarding .info files have already been created.

gagarine’s picture

gagarine CreditAttribution: gagarine commented

Why not letting people managing the version number manually?

Of course sometimes we are going to forget to bump version number... but it's a bug like any other bugs.

a.ross’s picture

a.ross CreditAttribution: a.ross commented

But if someone uses drush and they have a module on HEAD (not a stable release) how would you get the project to report a different version number (like 1.x-dev or what git_deploy currently does) than what's hardcoded by the maintainer?

gagarine’s picture

gagarine CreditAttribution: gagarine commented

By HEAD I guess you mean the master branch.

Imagine I work on two branchs for a project 7.x-2 and 7.x-1.

Like now for every stable version you can create a tag 7.x-2.1, 7.x-2.2 of course you will have to change the version number right before creating the tag.

You have two different workflow (at least):
- You commit everything in 7.x-2 branch and as soon as you released say 7.x-2.3 (by adding a tag) you change the version number to 7.x-2.4-dev and continue working until you are happy. To release the 7.x-2.4 you change you version number and again create a tag.
- You create branch for unstable code and merge them when you are happy and again change version number and add a tag.

In this way you version number doesn't depend of your branch name! And this is a good thinks.

a.ross’s picture

a.ross CreditAttribution: a.ross commented

No, that's not what I meant with HEAD: http://stackoverflow.com/questions/2529971/what-is-the-head-in-git

As for the workflows you describe, the first one is more work, and it's likely many maintainers will forget their "version change" commits. The second one is cumbersome for users, because which branch would one need to checkout to get the latest commits of the 7.x-1.x-dev version? Or the 7.x-2.x-dev version, if applicable to that project? And what to do about the -dev releases created by the d.o packaging script? These would also just fail, since there are no new commits in the appropriate branch.

As it stands, I still think a version file created by the packaging script has the least downsides. Any other ideas?

a.ross’s picture

a.ross CreditAttribution: a.ross commented

Release date also gets added by the packaging script, for example:

; Information added by drupal.org packaging script on 2012-05-17
version = "7.x-3.0-rc3"
core = "7.x"
project = "admin_menu"
datestamp = "1337292349"

I think that makes it pretty much impossible to maintain manually. No-go.

I'm becoming more confident that a dedicated .version file could contain exactly the above information with not-so-major changes to core and the packaging script.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

I'm not personally attached to how it works now, but there's no way we're going to a system that relies on manual effort by developers to get something right that's so easily (and already) automated. That's definitely "won't fix" material. ;)

That said, we can discuss moving this info into a separate file. However, what benefit would we gain by incurring the (rather large) cost of changing this? In the edge case that you're an advanced user that's deploying from Git instead of via a tarball, you'd have untracked changes in a separate file (which presumably you'd put in .gitignore?) instead of having those changes in a file already being tracked by Git? How is that a win? Why is that worth the effort? I still don't understand the original problem statement well enough to know why this is worth spending any energy on at all. People deploying from Git are power users in the first place, and they already have solutions they can use to solve these problems. Please explain why we need a change to the d.o packaging system and a coordinated change across multiple versions of Drupal core for this.

Thanks,
-Derek

a.ross’s picture

a.ross CreditAttribution: a.ross commented

Cross-linking: #1793074: Convert .info files to YAML

@dww: If I get what you mean, then that's not an issue. You wouldn't need a .version file when deploying with git, because the Git Deploy module could take care of reporting the version number, as it already does.
Looking at the issue I cross-linked, it seems a lot will change for D8 already in terms of packaging and storing module information. To me it would make a lot of sense to include this in the list of things to change. I don't think your concern holds, as this is a small change compared to the issue I linked to.

BTW, we could use the same format (f.Ex. YAML) as the .info file.

a.ross’s picture

a.ross CreditAttribution: a.ross commented
Title: Keep .info version data in the git repositories, rather than adding it by the packaging script » Separate version data from the .info file

Changing title, summary could also use some changes.

a.ross’s picture

a.ross CreditAttribution: a.ross commented

Another point in support of a separate .version file, is that version applies to projects, not to separate modules within a project. Currently, however, the project's version is applied to the project's modules. For example, the Commerce project contains a total of 12 modules, and the exact same version information is added to all 12 .info files.
A single version file in the root of the project, with a name like commerce.version (named after the project, not one of its modules) would be much more elegant.