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

[Andy Matuschak]

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
>
>
> 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
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/private.cgi/sparkle-andymatuschak.org/attachments/20070316/3ed76f5a/attachment.html