drush make could not locate latest recommended or supported release

I'm getting the same error.

7.16 is listed in the release XML:

http://drupal.org/files/release-history/drupal/drupal-all.xml

http://updates.drupal.org/release-history/drupal/all

http://updates.drupal.org/release-history/drupal/7.x

I tried:
drush cc drush

but that didn't help.

I have a script that uses drush 4.x, and that works, but 5.x fails.

I fixed it locally by manually removing the cache files:

rm -rf ~/.drush/cache/*

Based on the error message (found in commands/pm/release_info/updatexml.inc), this appears to be an issue with the update xml cache not being cleared via drush cc drush. Manually removing cache directories via rm -rf ~/.drush/cache/* appears to resolve the issue.

Just wanted to bump this as it happened to me today. rm -rf ~/.drush/cache/* does resolve the problem temporarily.

I have this problem too. When working with specific platform builds this is a big issue. We can not automate builds this way because the latest support release might not be what we need.

I have not been able to locate the origin of the problem better. When I have some time I'll try to digg in. The above mentioned solution does not work for me.

My apologies. I marked this as a major but when I use version numbers like 2.1 or instead of 7.x-2.1, as I had in my make file, it is no problem. Hope that someone can shed more light on this issue. When does this happen, with drush dl or with make files.

This patch clears all drush caches when `drush cc drush` is called instead of just 'default' and 'completion'. It will fix this issue, but will wipe out cached downloads.

Ouch. We are auto-clearing the Drush cache on every download, plus every time that "drush cc all" is called on any site -- which is frequently. Maybe we should clear all of this stuff whenever 'drush make' starts, but leave "drush cc drush" and "drush cc all" as-is? Alternatively, maybe just tuning down the TTL on the cached project info would be sufficient?

I'd prefer not to clear caches that shouldn't change (eg, git reference cache, and specific versions of downloaded tarballs/libs). Perhaps fixing this with a shorter TTL for release info would be sufficient?

Yes, I agree with #13. We should perhaps have a special 'hard' cache-clear to get rid of specific project versions in the cache, and otherwise keep them around for a really long time. Making the project info cache TTL really short would be a good idea and the best option, I think.

Making the project info cache TTL really short would be a good idea and the best option, I think.

This would fix the problems I've seen - as it has always (if memory serves) pertained to new releases not being downloaded when they are available.

From includes/cache.inc line 349

function set($cid, $data, $expire = DRUSH_CACHE_PERMANENT, array $headers = NULL) {
    $created = time();

    $cache = new stdClass;
    $cache->cid = $cid;
    $cache->data = is_object($data) ? clone $data : $data;
    $cache->created = $created;
    $cache->headers = $headers;
    if ($expire == DRUSH_CACHE_TEMPORARY) {
      $cache->expire = $created + 2591999;
    }
    // Expire time is in seconds if less than 30 days, otherwise is a timestamp.
    elseif ($expire != DRUSH_CACHE_PERMANENT && $expire < 2592000) {
      $cache->expire = $created + $expire;
    }
    else {
      $cache->expire = $expire;
    }

    // Ensure the cache directory still exists, in case a backend process
    // cleared the cache after the cache was initialized.
    drush_mkdir($this->directory);

    $filename = $this->getFilePath($cid);
    return $this->writeFile($filename, $cache);
  }

Forgive me, but not quite sure if the appended 2591999 and 2592000 are TTL? 720 hrs seems like its being made permanent.

So perhaps the project info TTL is set somewhere else...

Would be happy to write a patch with some help in the right direction.

I guess DRUSH_CACHE_TEMPORARY means keep it for 30 days, and other values for $expire means keep it that long -- the third parameter itself being used as the expiration time. Look at the code that caches the project information, and see what value it passes. If it passes DRUSH_CACHE_TEMPORARY, pick some new smaller value to use here. A day? Eight hours? Four hours? Something larger than the run of a make file, but smaller than the typical project release period.

Release info is currently cached for 24 hours, but could be cleared by passing in the cache-duration-releasexml option. I'm not sure that shortening this duration will fix the problem, since 1 day is pretty reasonable until security release emails go out and people are trying to update immediately.

From commands/pm/release_info/updatexml.inc

  // Some hosts have allow_url_fopen disabled.
  if ($path = drush_download_file($url, drush_tempnam($request['name']), drush_get_option('cache-duration-releasexml', 24*3600))) {

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.

I've created an issue report on the Github project at https://github.com/drush-ops/drush/issues/489