Hello, forgive me if this issue as been already covered or if it is not a Drush issue, but I have been experiencing the situation when running module updates through Drush, of having notifications of newer development versions of modules, but then when downloading the updates, Drush actually downloads the older stable release for the given modules. This issue has broken my site more then once in those cases where the -dev releases where needed to overcome bugs in the stable releases of the modules.

Comments

moshe weitzman’s picture

Status:Active» Closed (duplicate)
tuccio’s picture

Status:Closed (duplicate)» Needs review

With 567 open issues, would you bother linking to the main thread for those of us with little time to spare, when shutting down an issue as duplicate? Thank you.

tuccio’s picture

OK, for the meanwhile I found this old issue from 2010: http://drupal.org/node/760814 .
However, no conclusive result is mentioned.

Note: if a -dev release implies database changes, reverting to an older release can break a site. Therefore this issue seems quite serious and I hope someone can provide some more useful feedback than just marking it as a duplicate with no further explanation.

greg.1.anderson’s picture

Status:Needs review» Active

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

greg.1.anderson’s picture

Component:Base system (internal API)» PM (dl, en, up ...)
greg.1.anderson’s picture

Status:Active» Needs review
StatusFileSize
new3.94 KB

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.

hass’s picture

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)

greg.1.anderson’s picture

Is #7 what D8 does?

hass’s picture

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.

tuccio’s picture

I think the real problem is the downgrade from a -dev release to an older stable release.

In other words I was experiencing notifications of a newer (-dev) release but then the older stable release would get installed in odd cases (not always, and I don't know why). So, probably there actually was a newer -dev release available (thus triggering the notification) but then the older stable release would get installed instead (breaking the sites in several instances).

So I had to start checking case by case individually and verify the release dates for each upgrade. My point is that the release date of whatever is being installed should never be older than the current installation no matter whether stable or -dev. Of course a newer stable release could be preferable to a newer -dev release, but this was not the point of raising the issue. The timeline should only move in one direction.

Thank you so much for the help. Drush rocks (even with bugs, if any).

jonhattan’s picture

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

Project Installed Drupal -recommended Drupal - dev version Drupal - status Drush - proposed Drush - status
custom_permissions 7.x-2.x-dev (2011-Ago-31) 7.x-2.0 (2011-Jun-01) - None - Up to date 7.x-2.x-dev (2011-Ago-31) Up to date
entity_dependency 7.x-1.0-alpha1+7-dev (2012-Jun-01) 7.x-1.0-alpha1 (2012-Ene-31) - None - Up to date 7.x-1.0-alpha1 (2012-Ene-31) Up to date
entityreference 7.x-1.0-rc3+2-dev (2012-Jun-18) 7.x-1.0 (2012-Nov-18) 7.x-1.x-dev (2012-Nov-18) Update available 7.x-1.0 (2012-Nov-18) Update available
uuid 7.x-1.0-alpha3+47-dev (2012-Ago-27) 7.x-1.0-alpha3 (2012-Ene-31) 7.x-1.x-dev (2012-Nov-03) Update available 7.x-1.0-alpha3 (2012-Ene-31) Update available

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.

jonhattan’s picture

StatusFileSize
new1.63 KB

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.

greg.1.anderson’s picture

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

jonhattan’s picture

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.

greg.1.anderson’s picture

StatusFileSize
new2.74 KB

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.

greg.1.anderson’s picture

Priority:Normal» Major

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.

moshe weitzman’s picture

Assigned:Unassigned» jonhattan

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

moshe weitzman’s picture

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.

jonhattan’s picture

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

hansfn’s picture

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.

greg.1.anderson’s picture

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

hansfn’s picture

greg.1.anderson’s picture

Status:Needs review» Active

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

Carlos Miranda Levy’s picture

Version:» 7.x-5.8

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

greg.1.anderson’s picture

Version:7.x-5.8» 8.x-6.x-dev
Status:Active» Closed (won't fix)
Issue tags:+needs migration

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.