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

[Simone Manganelli]

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

 
On Friday, March 16, 2007, at 01:45PM, "Justin Bur" <jbur at druide.com> wrote:
>It's a bug in Sparkle. The comparison of the alphabetic component of  
>a standard version string is reversed.
>
>SUUtilities.m, in SUStandardVersionComparison(), line 144 (rev. 928,  
>head of the svn repository; a few lines earlier in Sparkle 1.1)  
>should read
>
>	NSComparisonResult result = [partB compare:partA];
>
>instead of [partA compare:partB].
>
>As an aside, in the Apple standard version scheme, the stage after  
>"b" is "fc", not "rc". In Apple terminology, you have "final  
>candidates" rather than "release candidates". See <http:// 
>developer.apple.com/technotes/tn/tn1132.html>. But this has no  
>bearing on the problem in Sparkle.
>
>justin