Contribute modules/themes should remove the "version" line from .info.yml, else will confuse update.module, from "Available Update" page and report with invalid package version information.
Here we link related patches for contribute modules/themes for simpler issue tracking.
Documentation for Drupal 7.x (https://www.drupal.org/node/542202#version):
version (Discouraged)
The version string will be added by drupal.org when a release is created and a tarball packaged. However, if your module is not being hosted on the drupal.org infrastructure, you can give your module whatever version string makes sense (eg. see Release naming conventions).
Documentation for Drupal 8.x (https://www.drupal.org/node/2000204#s-complete-example):
- Restricted properties, added by Drupal packaging system. Do not add these manually to info.yml in your repository.
version
project
Original issue summary by @nagy.balint:
Just like in this issue #2655474: version in info yaml confuses update reports, this module also has
version: VERSION
in the yaml file after a download from a make file or from git.But that will then display version 8.0.5 (or the version of the installed core), and that will confuse the reports.
The solution is to remove this line, like at the other module.
Comment | File | Size | Author |
---|---|---|---|
#9 | incorrect_version_02.png | 21.87 KB | nagy.balint |
#9 | incorrect_version_01.png | 8.79 KB | nagy.balint |
#2 | fix-info-yaml-2697787-1.patch | 454 bytes | nagy.balint |
Comments
Comment #2
nagy.balint CreditAttribution: nagy.balint commentedThis patch should fix the issue.
Comment #3
hass CreditAttribution: hass commentedComment #4
nagy.balint CreditAttribution: nagy.balint commentedwhy wont fix? Having the core version as the module version is certainly not the correct behavior.
This way I always have to use this patch if I want to install the module from a make file...
Comment #5
nagy.balint CreditAttribution: nagy.balint commentedI think that the module page displays 8.0.5 or whatever the core version is, and that it says unsupported release because of that, is certainly a bug, and not a support request.
Comment #6
Aron NovakIndeed, drush make workflows are broken with the current situation, it's a bug, even if not kind of highest priority, for sure.
Comment #7
hass CreditAttribution: hass commentedThis is not a bug. We always have done this for ages to make update status working while in development. This also does not confuse update status as it will be commented out from Drupal packaging. This happens on releases and also after every commit in the DEV packages. The
#
is the comment.No idea where you have seen a malfunction. If there is a software that is not able to understand the comment - than you need to file a bug against this module or Drush or Drupal Console.
Comment #8
hass CreditAttribution: hass commentedLet me know what component is confused by the YAML comment, please.
Comment #9
nagy.balint CreditAttribution: nagy.balint commentedThe issue happens when the code is pull from git directly.
For example drupal.make file:
This will produce the following in the info yaml
version: VERSION
And this will take the version of the drupal core.
See attached images.
Comment #10
nagy.balint CreditAttribution: nagy.balint commentedThis issue is also visible if you do a simple git clone:
git clone --branch 8.x-2.x https://git.drupal.org/project/google_analytics.git .
Then
less google_analytics.info.yml
will show:
Note that the comment sign is not there.
So this has nothing to do with drush actually. The comment sign is only put there by the packager on drupal.org when downloading the module in zip or tar formats.
Also visible here:
http://cgit.drupalcode.org/google_analytics/tree/google_analytics.info.yml
Comment #11
nagy.balint CreditAttribution: nagy.balint commentedComment #12
hass CreditAttribution: hass commentedWhy are you cloning dev for mske files?
Please use official releases only. DEV is not supported. Therefore cloning a dev to integrate into a distribution is - not supported. If you still think you need to use unstable software, you are on your own. Sorry.
Comment #13
nagy.balint CreditAttribution: nagy.balint commentedI still don't see why we would not remove that line, when it clearly provides no advantages, at least no other module i worked with on Drupal 8 has this line and those modules work fine for some reason. (And I already checked out several Drupal 8 modules for our own site).
Also in Drupal 8 most modules are experimental and unstable, so saying that i should use only stable, is kind of funny...
Comment #14
nagy.balint CreditAttribution: nagy.balint commentedNot to talk about the fact that often the dev release of a module is more stable than the last stable, and might have the feature i need. Its very often the case that there are no regular stable releases.
And when integrating to a project we can quickly check the stability of a dev release as well in most cases.
But either way I accept your decision, but if anyone needs this patch, its here, so they can use the dev version of this module in the future for whatever reason.
Comment #15
nagy.balint CreditAttribution: nagy.balint commentedComment #16
hass CreditAttribution: hass commentedBefore we close it I'd like to discuss this with core. There was a reason why we do this for ages, and i cannot remember why and if this reason exists no longer. However - i guess it still exists as core itself still uses VERSION and they also need to remove it than, isn't it?
Comment #17
hass CreditAttribution: hass commentedMoving to core after I tried some things. It looks like the underlying old bug may has been fixed in D8.
I'd like to ask core maintainers how to proceed here.
version = VERSION
inside it stays at "unsupported", but has a version8.1.0
.version = '8.x-2.0-dev'
changes the picture a bit and it looks supported and has a proper version.Well... nothing of these variants is really useful for a user except the last. I guess it can be removed now. Please confirm.
Comment #18
hass CreditAttribution: hass commentedAny chance to get answers without abusing priority?
Comment #19
alexpottAbusing issue priorities and queues suck. And now you put me in an impossible situation because I have some answers for your questions but if I answer them I'm condoning the behaviour. Which I don't want to do.
Comment #20
alexpottComment #21
alexpottBut hint... read the handbook https://www.drupal.org/node/542202
Comment #22
hass CreditAttribution: hass commentedThe most anoying thing is not receiving answers to this important questions.
Let's close these cases in my unimportant modules.
Comment #23
hswong3i CreditAttribution: hswong3i commented@hass: agree with #17 so this ticket should belongs to Drupal core.
Also, as @alexpott mentioned at #21, https://www.drupal.org/node/542202 already mention version as discouraged for Drupal 7.x:
Here I link my related patches for contribute modules to this ticket for simpler issue racking.
Shall we create corresponding document page similar as https://www.drupal.org/node/542202 but for Drupal 8.x? So we can advice contributors to remove legacy "version: VERSION" from their .info.yml?
Comment #24
alexpott@hswong3i sure create the page - that'd be great - not sure we need an issue open to do that though.
Comment #25
hswong3i CreditAttribution: hswong3i commentedComment #33
hswong3i CreditAttribution: hswong3i commentedComment #34
hswong3i CreditAttribution: hswong3i commentedComment #35
dwwThere's no bug in update.module here.
We've never recommended anyone ever define version = X in their .info files.
Either sites should deploy from officially packaged releases (which have the proper metadata injected), or you were supposed to use cvs_deploy (back in the CVS days) or now git_deploy if you're trying to deploy directly from a Git checkout and don't have the proper metadata in your .info files.
But maintainers putting
version = VERSION
in their info files is definitely wrong. That never helped anything.Closing this as a "by design" support request.
Thanks,
-Derek