[Sparkle] Avoiding an incompatible update

[Andy Matuschak]

The latter, I'm afraid: it's a simply-implemented element. Also, you  
have to remember to specify the minimum system version for all future  
releases after that.

Someday, this'll be improved.

- Andy Matuschak

On Jan 22, 2008, at 9:48 AM, Mark Munz wrote:

> So does that mean you can have a single feed offering up two different
> versions of your product based on the System version of the end user?
> Or that it just won't see the future releases if it doesn't meet the
> minimumSystemVersion requirements?
>
> Mark
>
> On 1/20/08, Andy Matuschak <andy at andymatuschak.org> wrote:
>> Whoa, whoa, it's way simpler than all this: there's a
>> sparkle:minimumSystemVersion element supported in trunk. I don't  
>> think
>> it's documented, but just put the minimum system version for the
>> version in question as the value of that element as a child of the  
>> RSS
>> item.
>>
>> - Andy Matuschak
>>
>> On Jan 20, 2008, at 6:09 PM, Justin Bur <jbur at druide.com> wrote:
>>
>>> SparklePlus, which I think Andy has incorporated into the trunk now,
>>> allows sending various system profile information as arguments on  
>>> the
>>> http request for the appcast. The appcast is not a fixed xml file,
>>> but rather a php script that interprets these arguments for
>>> statistical purposes – or for customizing the appcast.
>>>
>>> Although it is considered polite to ask permission before
>>> transmitting people's system details, I think it is legitimate to
>>> send just the system version number, if that is a piece of
>>> information you need to offer the correct update. The rest of the
>>> profile information should not be sent (the code to compile and
>>> transmit it should be commented out).
>>>
>>> The only problem with this solution is that it won't help you unless
>>> you've adopted it for the release *before* the one that needs to
>>> decide whether you're on Tiger or Leopard... you can't really  
>>> upgrade
>>> in the field!
>>>
>>> Justin
>>>
>>> On Jan 20, 2008, at 17:21, David Dunham wrote:
>>>
>>>> I'm planning a Leopard-only update, and realized that I don't have
>>>> anything in place to prevent a user running Tiger from updating to
>>>> this version. How are people handling this?
>>>>
>>>> One thought that crossed my mind was to switch the URL that Sparkle
>>>> uses. This would allow the Leopard only version to have Sparkle
>>>> updates. And it would keep Tiger users safe. But it would prevent
>>>> Leopard users from learning about the update.
>>>>
>>>> David Dunham           A Sharp, LLC           +1 206 783 7404
>>>> The Opal outliner is now available!  http://a-sharp.com/opal/
>>> _______________________________________________
>>> Sparkle mailing list
>>> Sparkle at lists.andymatuschak.org
>>> http://lists.andymatuschak.org/listinfo.cgi/sparkle- 
>>> andymatuschak.org
>> _______________________________________________
>> Sparkle mailing list
>> Sparkle at lists.andymatuschak.org
>> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org
>>
>
>
> -- 
> Mark Munz
> unmarked software
> http://www.unmarked.com/
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org