Pass Sparkle's guess for the best update to -updater:bestValidUpdateInAppcast

[andymatuschak]

**dwood (dwood-karelia)* reported (on Launchpad) on' 2008-09-02:*

Some clients might want to perform logic for choosing an update based on what Sparkle's guess it. Or under some circumstance, it might want to fall back to the default choice.

Original:

"Not sure how to reproduce this, but I had a user running Sparkle (1.5b4 or b5-ish) from an slightly older version, and he was being informed that his version was the latest version. But it wasn't. I get reports like this from time to time.

it would be useful to have a hidden user default to log exactly what appcast URL Sparkle is using, so we could diagnose this if we get reports from user.

I've been looking through the source and it seems like most URL requests are correctly using the 'ignoring cache' policy. There is on in SUBasicUpdateDriver that should probably use the cache-policy variation: requestWithURL:cachePolicy:timeoutInterval:

• (void)downloadUpdate { download = [[NSURLDownload alloc] initWithRequest:[NSURLRequest requestWithURL:[updateItem fileURL]] delegate:self];
  }

Sorry if this report seems to ramble -- mostly I'm just trying to diagnose issues of the app thinking it's up to date when it really isn't."

[andymatuschak]

**Hofman (cmhofman)* wrote on 2008-09-02:*

The appcast ignores the cache, and AFAIK always has. Certainly it does so in 1.5b4 and 1.5b5.

As for downloadUpdate, I doubt it is relevant that it does not ignore the cache, as you should never have to download the same update more than once.

BTW, I don't think it's a good idea to log every check.

[andymatuschak]

**dwood (dwood-karelia)* wrote on 2008-09-02:*

I don't think it's a good idea to log every check either -- but it would be useful to have a hidden default to turn on so that we could get some decent detailed logging for troubleshooting. Because, empirically, there are problems here and I'd like to find out why.

[andymatuschak]

**Hofman (cmhofman)* wrote on 2008-09-03:*

I still don't think it's a good idea for Sparkle to add such a hidden default. Perhaps instead Sparkle could make it possible to let you do this yourself using delegate methods. This would be possible if -bestValidUpdateInAppcast:forUpdater: would be replaced by -bestValidUpdate:inAppcast:forUpdater: (i.e., the updater would pass it's own guess in the delegate method). This would allow the client to know which update item Sparkle finds, and do whatever it deems necessary.

Attached is a patch for this (also fixes a memory management bug).

Also, are you sure you pass the correct version info, and the version is given in an appropriate format?

[andymatuschak]

**Andy Matuschak (andymatuschak)* wrote on 2008-09-04:*

Hm. Curious bug. I'm not sure what's going on there, but I think you should keep that patch local to your branch for now. I need to think of a better selector for that delegate method if it's going to be providing Sparkle's pick.

[andymatuschak]

**Hofman (cmhofman)* wrote on 2008-09-04:*

-updater:bestValidUpdateInAppcast:suggestion: perhaps?

BTW, small thing, but the updater argument names in some delegate methods should be changed from 'bundle' to 'updater'.

[andymatuschak]

**Andy Matuschak (andymatuschak)* wrote on 2009-01-05:*

Not for 1.5.