@,

drush pm-update

i get,

...
Update status information on all installed and enabled Drupal projects:
Name Installed version Proposed version Status
...
CAPTCHA 6.x-2.x-dev 6.x-2.1 Update available
...
Code updates will be made to the following projects:
CAPTCHA [captcha-6.x-2.1]
...

Checking,

drush pm-releases captcha
Project Release Date
captcha 6.x-2.1 2010-Jan-01
captcha 6.x-2.0 2009-Sep-23
captcha 6.x-2.0-rc3 2009-Aug-27
captcha 6.x-2.0-rc2 2009-Jul-03
captcha 6.x-2.0-rc1 2009-Jun-13
captcha 6.x-2.0-beta5 2009-May-17
captcha 6.x-2.0-beta4 2009-Apr-24
captcha 6.x-2.0-beta3 2009-Apr-06
captcha 6.x-2.0-beta2 2009-Feb-02
captcha 6.x-2.0-beta1 2009-Jan-03
captcha 6.x-2.x-dev 2010-Mar-17
captcha 6.x-1.0-rc2 2008-Apr-11
captcha 6.x-1.0-rc1 2008-Feb-15
captcha 6.x-1.x-dev 2010-Jan-08

why is drush not 'offering' the *latest*,

captcha 6.x-2.x-dev 2010-Mar-17

which is also consistent with the version I have installed,

drush pm-list | grep \(captcha\)
Spam control CAPTCHA (captcha) Module Enabled 6.x-2.x-dev

Is there a config, or cmd line, option required?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

Status: Active » Fixed

drush downloads/udates to the *recommended* release, by default. thats not always latest. if you want a different release, specify it in dl command.

a5342346’s picture

I'd clearly misunderstood that. Thanks for clearing up!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

bpeter’s picture

Category: support » bug
Status: Closed (fixed) » Active

In my case I have for example ubercart-6.x-2.x-dev (2010-Feb-13) installed on a site.

When I run drush pm-update it offers ubercart-6.x-2.2 as the proposed version which is older (2009-Nov-18) but for example subdomain-6.x-1.x-dev (2010-Feb-07) installed on this site which has a recommended version (subdomain-6.x-1.7) which is older (2009-Dec-31) drush displays it as the proposed version but does not offer as an update.

Drush offers an update only when a newer (development) release available but it always offers the recommended release as an update even if it is older than the installed development release. So admin/reports/updates page must be checked for every single installed development release which has update available in drush and use drush dl for update and cannot run a pm-update to update the entire site without the risk to downgrade some modules which is almost certainly breaks the site.

So this can be corrected if drush not offers recommended releases as an update when newer (development) release installed. It can offer development release update in this case or do not offer update at all. So drush pm-update can become safer to use.

moshe weitzman’s picture

I'm a bit weary tracking all the cases here in updatecode command. Anyone willing to take this on?

greg.1.anderson’s picture

Assigned: Unassigned » greg.1.anderson

I'm willing, and familiar enough with the update code to do it; the only thing I'm short on is time. I guess it depends on who circles back for the updatecode rewrite first, me or Owen. I'll take it for now.

Dane Powell’s picture

Subscribing - I'd like to see either the update code get "smarter" as mentioned, or prompt for each individual module whether to upgrade or not / which release to upgrade to. As it is, I cannot run pm-update for the entire site if even one module is on a dev release - I must update each module individually. Very annoying.

MyXelf’s picture

Component: Code » PM (dl, en, up ...)

Subscribing...

jstoller’s picture

This bug has become a huge nuisance and I would love to see it fixed.

I'll add one more quirk to the problem. I'm using realname-6.x-1.x-dev. As others have mentioned, when a new Real Name dev release is posted, Drush tries to downgrade me to realname-6.x-1.3, which was released more than a year ago. However, if I try using "drush up realname-6.x-1.x-dev" to upgrade to the latest dev release, Drush tells me I already have it installed. This is another area I would like to see the update code get a little smarter.

Finally, you might want to look at #802074: drush - updates to lower version?, which may or may not be a related issue.

greg.1.anderson’s picture

For a workaround, see update_advanced.

jstoller’s picture

If I understand correctly, update_advanced will allow me to stop updates to a specific module all together, which is far from ideal. If I'm using a dev version, then I want to be notified of newer dev releases, as well as newer official releases. I just don't want to be downgraded to an old "recommended" release.

greg.1.anderson’s picture

Yes. I have used update_advanced to successfully prevent drush from messing with a module at pm-update time, but you are right, that is not a solution in this instance. I mis-spoke.

greg.1.anderson’s picture

Assigned: greg.1.anderson » jonhattan

Just noticed this is still assigned to me... maybe jonhattan would like to take a crack at it? Still trying to get through my important sql & alias issues...

Zach Harkey’s picture

I had a long bloodbath with this issue. I had several sites running panels-6.x-3.x-dev that were constantly being downgraded to panels-6.x-3.7. I started thinking I must have a fundamental misunderstanding of how -dev tags were used.

The weird thing is that the behavior seemed inconsistent: some modules would update to the latest -dev while others would 'down'date to the last release. I'm not positive, but it seemed like I could break the cycle by rm -r the entire project dir and doing a fresh drush dl to the latest -dev, which made me wonder if it had something to do with whether or not you drush updated to the -dev release vs. drush downloaded the -dev release from scratch.

jstoller’s picture

Correct me if I'm wrong, but if you drush dl a module you already have installed, doesn't it overwrite the entire module with the new version? I don't think it's necessary to remove the directory before downloading the update. If it does, then I've been doing it wrong for quite some time now.

When I see drush wants to "upgrade" me from a dev release, I first check the project page to see if its actually an upgrade, or if there was just a new dev release. Assuming its just an updated dev, then I do drush dl to download the latest dev and overwrite my existing dev. Then drush stops complaining. These extra steps have a tendency to slow down my workflow quite a bit.

greg.1.anderson’s picture

Just some notes; I looked this over a bit today.

Today, pm-updatecode relies on the update status module to determine which modules need code updates, whereas pm-download fetches and parses the project xml directly. In order for this to work, I think that we need to use (edit: the existing project data structures) to check to see if the version is '-dev', and if so, use the same technique as pm-download to fetch and examine project information.

This will require some factoring of the pm-download code.

greg.1.anderson’s picture

No, I'm wrong in #16; update status gets it right, and recognises that there are two releases with the same tag, but on different dates. The confusion comes later, in drush, I think... Still looking.

greg.1.anderson’s picture

Status: Active » Needs review
FileSize
983 bytes

I was looking at the logic some more, and there are multiple places where the wrong decision can be made. It seems that it would be cumbersome to update all of the spots that need adjusting, so I took a more pragmatic approach.

The enclosed patch waits for drush to finish deciding what the candidate version should be, and then tests to see if the candidate version is older than the installed version (just like the title of this issue says). If it is, then the candidate version is set to the installed version.

In the case of a 'dev' release, the version number of the latest release is the same as the version number of the installed release, even when there are updates available. The code that ran before has already correctly identified whether an update is needed or not, though, so you might see "Panels 6.x-3.x-dev 6.x-3.x-dev Up to date", or you might see "Panels 6.x-3.x-dev 6.x-3.x-dev Update available" depending on whether or not the latest dev version is the same as or newer than the installed version.

This has been only lightly tested, and there might be unintended consequences. For example, you won't be able to use pm-updatecode to deliberately downgrade your module any more -- but that was never advisable anyway.

It would be very helpful if the various subscribers on this issue could install this patch (presumably if you are running 'dev' versions of modules you have a site where you can do that safely...) and see how it performs.

jonhattan’s picture

FileSize
1.34 KB

Thanks Greg. That works in my scenario (zen 2.x from 2009-Dec-18 updated to 2.x from 2010-Nov-12). I did take a look to this some days back with that approach:

 function pm_release_recommended(&$project) {
-  if (isset($project['recommended'])) {
+  // If the project is a dev release and is of one of the supported versions
+  // update to new version of the same release.
+  if (($project['install_type'] == 'dev') && (strpos($project['supported_majors'], $project['existing_major']) !== FALSE)) {
+    $project['candidate_version'] = $project['existing_version'];
+    $project['updateable'] = TRUE;
+  }
+  elseif (isset($project['recommended'])) {
     $project['candidate_version'] = $project['recommended'];
     $project['updateable'] = TRUE;
   }

It fixes for the update process but once the project is updated, updatecode shows:

Installed         Proposed            Status
6.x-2.x           6.x-2.0               Up to date.

and I got stalled in the way to solve this alltogether. Wait, now that I see update status page that's what is shown:

Zen 6.x-2.x-dev (2010-Nov-12)
Recommended version: 	6.x-2.0 (2010-Jun-26)

So attached is my code as an alternative solution.

ergophobe’s picture

Thanks so much for this patch. This fixes a major usability issue with Drush.

Short answer: it worked.

Longer answer.

I ran it on a site with two dev modules (wysiwyg and uc_views). It correctly caught that the modules were out of date. Unfortunately, for whatever reason, uc_views has a release date of 18 Nov, but it has a datestamp in the info files of 12 Nov. It also does not match the checksum given.

So I downloaded it, extracted it, did a complete file compare to the existing version that I have working and there were no differences, except the datestamps in the .info files. So I deemed it safe and did a search and replace for all datestamps and set them to 19 Nov.

I then ran drush up again and it flawlessly updated the wysiwyg module.

So because of the problems with the uc_views module, I only did one update on one module. So far so good though.

This patch is great!

jonhattan’s picture

@ergophobe did you test patch in #18, #19 or both?

greg.1.anderson’s picture

I think that #19 is better than mine, as the update status in drush matches the update status in Drupal.

Edit: Actually, I think the positioning of the patch as in #18 is better. pm-updatecode then shows you the version that you're going to get in the current update operation. If the user cares to see what recommended versions are available, pm-releases can provide that information.

Some of the tests in johnattan's patch should be rolled into mine for improved safety, though.

jonhattan’s picture

Assigned: jonhattan » greg.1.anderson

Ok. your positioning also is better for --pipe. My tests are not based on release dates. I'm not sure how you want to merge them.

greg.1.anderson’s picture

Status: Needs review » Needs work

I'll roll a new patch...

ergophobe’s picture

Shoot! didn't even see patch #19. I tested #18 only - greg1's patch. Sorry.

greg.1.anderson’s picture

Status: Needs work » Reviewed & tested by the community

On further review, I have decided to put forward patch #18 without modification as a candidate to be committed.

I don't think that we should test ($project['install_type'] == 'dev'), as it is possible that some project might release a series of supported releases that are newer than the recommended release. If drush should decide to go back from a supported release to the recommended release, then we would want the date-based check to stop this from happening. I don't think drush will ever do this, but in any event it does not appear to hurt to leave off the 'dev' test.

I also think we should not include the (strpos($project['supported_majors'], $project['existing_major']) !== FALSE) test. It is possible that someone might have a dev version where the major version is not supported. We still want the date-based check to take effect in this scenario as well.

I have not thought of any additional safety checks that we should add to #18. Per #20 I am setting this to 'reviewed', and I leave it to jonhattan to commit or revise as necessary.

jonhattan’s picture

Status: Reviewed & tested by the community » Fixed

Ok. Commited #18. I only changed comments to fit 80 chars per line. I don't know if you have a reason to extend to ~50 chars or it's just a question of personal taste :)

greg.1.anderson’s picture

Priority: Normal » Critical
Status: Fixed » Patch (to be ported)

Personal laziness, maybe. :) Thanks for fixing my formatting.

If there is a drush 3.x release before we get 4.x our, then this one should definitely go in.

ergophobe’s picture

As i say - #18 is great as far as my test went.

Thanks so much guys - glad to have this as part of All-Versions-HEAD so I don't have to keep applying the patch.

Much appreciated.

moshe weitzman’s picture

Version: » All-versions-3.x-dev
moshe weitzman’s picture

Status: Patch (to be ported) » Fixed

3.x gets security fixes only.

joachim’s picture

Version: All-versions-3.x-dev » All-versions-4.x-dev
Status: Fixed » Active

Was this fixed in 4.x?

I'm on 4.3 dev and I just got this:

There is no recommended release for project services.
Choose one of the available releases:
 [0]  :  Cancel                                      
 [1]  :  5.x-1.x-dev  -  2011-Feb-25  -  Development 
 [2]  :  5.x-0.91     -  2008-Jun-19  -  Security    

The final 5 release of Services is 0.92...

greg.1.anderson’s picture

Status: Active » Fixed

services -5.x-0.92 is not marked 'supported' or 'recommended' or 'security' or even 'development', so it is not shown by default. Run with --all to see all of the choices, and then you will be able to select it.

If one wanted to split hairs, one could argue that it does not make sense to show non-recommended, non-supported security releases. That would be true, but should be discussed in a separate issue if deemed important enough to haggle over.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.