Drush up notifies of -dev version update but then installs older stable release

#760814: drush pm-update offers to update to an older release than currently installed, and misses the newest available release was committed to Drush-4.x in http://drupal.org/node/760814#comment-3734700; however, I did note that the behavior described here is still in fact happening. I have a site with an old version of uuid 7.x-1.0-alpha3+31-dev from April 2012, and Drush wants to update it to the older uuid 7.x-1.0-alpha3 from January 2012 instead of the latest 7.x-1.x-dev from 3 November.

We also have the similar related issue #1518036: Drush up does not update to latest recommended release. #1308836: D7 module will not update from dev version to release version is also related, and maybe a duplicate of #1518036. Ditto #1323046: How can I upgrade from Drupal Core dev to stable?. Ditto #1204904: installs wrong package version when a later version is available. All of these want to be able to upgrade from dev to stable. However, I can't find an open duplicate of this issue, which notes that Drush will sometimes "upgrade" to an older release, so the status here should be active, unless the dup issue shows up.

Here's a patch to improve the situation. Dev releases can only be updated to newer dev releases, unless the --stable option is specified, in which case dev releases can only be updated to newer stable releases.

Feedback welcome.

This is not what I pleased for in #1518036: Drush up does not update to latest recommended release. --stable should be the default and dev to dev only until there is no newer official release available (e.g. based on timestamp)

Is #7 what D8 does?

I don't know what D8 does, but updating dev to next official release makes a lot of sense. I normally install dev's only to get bugs solved that are not fixed in an official release. I do not like to stay with unstable dev's forever... This is something that maintainers of a module may like, but this is far less than 0.1% of all installations... Maybe D8 need to change, too if it's not working this way.

I've been debugging this issue, here're my notes:

custom_permissions: OK. Up to date: the dev version is newer than the stable one.

entity_dependency: OK. Up to date: the recommended version is older than the installed dev. NOTE: Drush is aligned with Drupal report. It proposes the stable one, but considers the module up to date.

entityreference: Update available. OK: The recommended version is newer than the dev installed. There's also a newer dev version. Drush proposes the Drupal recommendation. This is what people expect as in comment #7.

uuid: Update available. FAIL: There's a update available but drush picks the recommended version instead of the latest dev.

NOTE: Drush is aligned with Drupal report, and the consequence of this is wrong: it wants to update a dev version to an older stable release because there's a newer dev version.

Greg: I was working in a similar solution to yours based on my findings, but with no extra features.

There's a big difference: mine updates dev to stable if there's a newer stable. Otherwise, if there's a newer dev it will pick it.
I've no strong preference. I came to this solution because it was straight ahead.

My patch is of less complexity and I think it intervenes in a more precise place/function. It needs more testing. Perhaps both approaches will met: I'll be fine with your patch based on $project['install_type'] == 'dev' and $project['latest_dev'].

BTW, I'm concerned about the complexity of updatecode. It needs a cleanup. Some code is there since Drupal 5, when update were done by contrib update_status module.

#12 is better than #6; I agree that the behavior of #7 is preferable.

I haven't had time to test, but the code looks better, and definitely simpler. The one thing I want to look further is the placement of this code:

      if ($project['releases'][$project['candidate_version']]['date'] <= $project['info']['datestamp']) {
        $project['updateable'] = FALSE;
      }

I remember that there were a number of places in the pm-updatecode code path where Drush indiscriminately picked a release without regard to its release date vis-a-vis the date of the installed dev version. If all of these places do so by calling pm_release_recommended, then #12 is good as written.

I agree that the pm-updatecode as a whole is in need of maintenance and deeper rework. The code that updates Drupal core was supposed to be temporary, and was squeezed in just to get something that worked into Drush 3. I haven't had a chance to circle back to it yet myself. c.f. #759906: Update core without moving core files out of the way.

All valid projects that are not already in its latest/recommended version go through pm_project_filter() -> pm_update_filter() -> pm_release_recommended(). It seems the best candidate.

I reviewed the code paths again, and I almost agree with #14, but not quite. pm_update_filter might change the candidate version if the latest dev release is installed. This will cause the output of the update report to look something like this:

Universally Unique ID (uuid) 7.x-1.0-alpha3+51-dev 7.x-1.0-alpha3 Up to date

In this example, 7.x-1.0-alpha3+51-dev is newer than 7.x-1.0-alpha3,but from the report, it looks like 7.x-1.0-alpha3 is the candidate version. "Up to date" contradicts this. Perhaps the display should be consistent with the output for up-to-date modules at stable releases, and repeat the installed version number:

Universally Unique ID (uuid) 7.x-1.0-alpha3+51-dev 7.x-1.0-alpha3+51-dev Up to date

Another thing of note is that when an update is available for dev module, the update report will say something along the lines of:

Universally Unique ID (uuid) 7.x-1.0-alpha3+31-dev 7.x-1.x-dev Update available

During the update, it is reported that uuid was successfully updated to version 7.x-1.x-dev. Once the update has completed, though, the version of uuid will once again be reported to be something along the lines of 7.x-1.0-alpha3+51-dev. Would it be better to report that the available version is 7.x-1.0-alpha3+51-dev? I am not sure if this version number appears anywhere other than the .info file -- haven't had time to look into this further. The attached patch therefore addresses the first issue, but not the second.

Updating to 'major', since this fixes the problem where Drush will "update" from a newer to an older release. I would even call this "critical", except it only applies to dev releases.

Would be great if jonhattan could review and commit this. If not, greg is welcome to do so in a few days.

If folks want to add tests, that would be great. I think the tests supply their own updateXML so we can manufacture scenarios as needed.

Committed #15. We don't know the latest dev for uuid is 7.x-1.0-alpha3+51-dev from the update xml.

Also committed a fragment of the patch in #6: add the project date to pm-info. http://drupalcode.org/project/drush.git/commit/cc12bb8

Now I'll try to write a test from tests/devel.xml

OK, I was about to report a new issue about make-generate followed by make, installs the latest stable version in stead of the latest dev, but I think it's a duplicate of this one. Example:

$ drush make-generate > ../test.make
$ grep dev ../test.make
projects[coffee][version] = "2.x-dev"
projects[views_send][version] = "1.0-alpha1+6-dev"
$ cd ../somedir
$ drush make ../test.make
Make new site in the current directory? (y/n): y
Could not locate views_send version 7.x-1.0-alpha1+6-dev, will try to download latest recommended or supported release.
[...]

In my opinion the problem is that make doesn't recognize 7.x-1.0-alpha1+6-dev as a dev version. (Notice that a dev version without a stable release, like coffee above, works like expected.)

PS1! Just tell me if I should create a new issue after all.
PS2! The test above was done with Drush from the 8.x-6.x branch as of today.

I think that #20 is a new issue, and was caused when the format of dev versions changed from 1.0-alpha1-dev to 1.0-alpha1+6-dev, confusing make-generate. In other words, I think this is a make-generate bug, not a pm-* bug (separate issues with the same root cause).

#20 moved to #1859706: make installs the latest stable version in stead of the latest dev.

Is this open just for tests, or can this be closed now?

Just ran into this issue for media and file entity 2.x dev
So I guess this should remain open.

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.