[Sparkle] Sparkle Not Finding Update with Different Style Version Number

[Justin Bur]

Here's an idea that might be able to handle just about all cases the  
"right" way.

First, use CFBundleGetVersionNumber() to convert a genuine Mac OS 9- 
style 'vers' string into a numeric value, and if this works (how do  
you tell? the documentation is unclear), do the official TN1132  
contorted comparison to figure out which version is newer.

If CFBundleGetVersionNumber() fails, fall back on the current  
algorithm as corrected by my fix, so that the version string is  
broken into segments and then each segment sorted in standard  
alphanumeric sequence.

Yes, for the sake of tradition and compatibility, 'd' should sort  
before 'a', 'b', and 'fc', and CFBundleGetVersionNumber() should take  
care of it. On the other hand, the old TN1132 system is fading away,  
and d-for-development version numbers are probably very rare in the  
Mac OS X/Cocoa world. Even Launch Services doesn't bother with d/a/b/ 
fc; see this posting from an Apple engineer: <http://lists.apple.com/ 
archives/carbon-dev/2006/Jun/msg00139.html>

In my own use of Sparkle, I have moved the version-comparison logic  
to the update server. On the model of SparklePlus, I send the current  
app version as an argument to a script on the server. This script  
then generates a custom appcast for that particular request. By  
keeping the application side as general and dumb as possible, I hope  
to be able to handle any future requirements by simply adjusting my  
server-side script. I have also modified Sparkle to be able to  
present RSS items that don't contain an enclosure, for the purpose of  
paid upgrades that require more complex interaction with a web  
browser. (I'll contribute code if this feature is of interest for the  
standard version.)

justin


On Mar 16, 2007 at 17:32, Andy Matuschak wrote:

> The problem with just using the publishing date is that if you're  
> using an unreleased beta, then if you don't have any version  
> comparison, the latest version in the official appcast appears to  
> be a new version, even though it's actually older. I guess the app  
> could have a release date key in it, too, though that's kind of a  
> hack.
>
> - Andy Matuschak
>
> On Mar 16, 2007, at 2:28 PM, Simone Manganelli wrote:
>
>> Hmm.  But if Sparkle is taking its cues from Apple's official  
>> versioning system (from the same technote), then "1.0d1" should  
>> come before "1.0a1".  If that's the case, then Sparkle would fail  
>> to find the 1.0a1 update when using version "1.0d1", since "a"  
>> comes before "d" in the alphabet.
>>
>> Wouldn't it make more sense to just use the publishing date in the  
>> appcast?  That is, if a certain version is released on date  
>> 2007-03-16, and a certain other version is released on 2007-03-18,  
>> then the version released on the 18th should be a later version,  
>> no matter if the version numbers are "1.0a1", "3.0.g.7.e", or  
>> "funky_version_number_5".
>>
>> If a developer wanted to maintain separate trees... e.g..: if they  
>> released version 2.0 which required a paid upgrade, but kept  
>> fixing bugs in the 1.x cycle, the developer could maintain two  
>> separate appcasts, one for the 2.x branch, and one for the 1.x  
>> branch.  (I can forsee a bit of a problem in whether a 1.x version  
>> presents a dialog for a 2.x update or a later 1.x update, though.)
>>
>> -- Simone