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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nagy.balint created an issue. See original summary.

nagy.balint’s picture

hass’s picture

Category: Bug report » Support request
Status: Needs review » Closed (won't fix)
nagy.balint’s picture

why 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...

nagy.balint’s picture

Category: Support request » Bug report

I 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.

Aron Novak’s picture

Status: Closed (won't fix) » Needs review

Indeed, drush make workflows are broken with the current situation, it's a bug, even if not kind of highest priority, for sure.

hass’s picture

This 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.

hass’s picture

Status: Needs review » Postponed (maintainer needs more info)

Let me know what component is confused by the YAML comment, please.

nagy.balint’s picture

The issue happens when the code is pull from git directly.

For example drupal.make file:

  google_analytics:
    type: module
    download:
      type: git
      url: http://git.drupal.org/project/google_analytics.git
      branch: 8.x-2.x
      revision: 64eaef0c725aa17cb90cfddf6860ccf64e7f9b4e

This will produce the following in the info yaml
version: VERSION

And this will take the version of the drupal core.
See attached images.

nagy.balint’s picture

This 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:

name: 'Google Analytics'
type: module
description: 'Allows your site to be tracked by Google Analytics by adding a Javascript tracking code to every page.'
package: Statistics
version: VERSION
core: 8.x
configure: google_analytics.admin_settings_form
test_dependencies:
  - php:php
  - token:token

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

nagy.balint’s picture

Issue summary: View changes
hass’s picture

Why 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.

nagy.balint’s picture

I 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...

nagy.balint’s picture

Not 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.

nagy.balint’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)
hass’s picture

Status: Closed (works as designed) » Postponed (maintainer needs more info)

Before 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?

hass’s picture

Project: Google Analytics » Drupal core
Version: 8.x-2.x-dev » 8.1.x-dev
Component: Code » update.module
Status: Postponed (maintainer needs more info) » Active

Moving 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.

  • In past we manually added version key to info file to allow people to install DEV versions from GIT/CVS. Update status module was confused if this version was missing and has not shown the module any longer on the update page as I know.
  • Now it looks like this is switched to an "unsupported" state and "Unknown" version if I remove all version lines.
  • If I leave version = VERSION inside it stays at "unsupported", but has a version 8.1.0.
  • If I leave 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.

hass’s picture

Version: 8.1.x-dev » 8.2.x-dev
Priority: Minor » Critical

Any chance to get answers without abusing priority?

alexpott’s picture

Project: Drupal core » Google Analytics
Version: 8.2.x-dev » 6.x-4.x-dev
Component: update.module » Code
Priority: Critical » Minor

Abusing 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.

alexpott’s picture

Version: 6.x-4.x-dev » 8.x-2.x-dev
alexpott’s picture

But hint... read the handbook https://www.drupal.org/node/542202

hass’s picture

Status: Active » Closed (works as designed)

The most anoying thing is not receiving answers to this important questions.

Let's close these cases in my unimportant modules.

hswong3i’s picture

Project: Google Analytics » Drupal core
Version: 8.x-2.x-dev » 8.2.x-dev
Component: Code » update.module
Priority: Minor » Normal
Status: Closed (works as designed) » Needs review

@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:

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).

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?

alexpott’s picture

@hswong3i sure create the page - that'd be great - not sure we need an issue open to do that though.

hswong3i’s picture

Issue summary: View changes

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

hswong3i’s picture

Issue summary: View changes
hswong3i’s picture

Issue summary: View changes
dww’s picture

Category: Bug report » Support request
Status: Needs review » Closed (works as designed)

There'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