[Sparkle] Thinking about unifying Sparkle...

[Andy Matuschak]

On Aug 4, 2007, at 8:11 PM, David Symonds wrote:
> A bunch of awesome stuff on posets.

This is really (probably overly) fancy but at the same time very cool.  
I like the idea of being able to update beta testers while at the same  
time releasing main-line bugfix releases. There are some  
implementation details we'd have to muddle with. I'm not sure this'd  
be very happy living in XML like the rest of the appcast; it doesn't  
really allows hierarchies of items, so we'd have to have some kind of  
header with this information. But something like  
<sparkle:versionordering>0.1 < 0.2 < 0.99b1 < 1.0</ 
sparkle:versionordering> is so ugly and we totally can't do that.

It's also really important that branches be named. The problem is that  
if the tree can be branched at any one time, we can't just have a  
plain preference for something like "development releases" vs "public  
releases", etc. I really want to keep the prefpane UI simple.

I do want to make an app to create and update appcasts with minimal  
data entry, but I'm not sure how I'll do this kind of thing in that  
UI, either. Thought is required.

On Aug 4, 2007, at 10:58 PM, Steven W Riggins wrote:
> In fact, Sparkle should be a generic installer as well, in other
> words, apps can register what should be uninstalled.

I'm sorry, I don't understand what you mean by this. What should be  
uninstalled? So that you can remove an app, too, and all its stuff in  
Library, etc, will go away?

> Also some apps, like shareware Snak, will stop working if you get a
> version 2 years past the date you licensed it, without a new
> license.  If Sparkle could handle THAT it would rock.  "There is a
> new version of Snak available, but it requires a new license..."

I would like to handle this. Snak has a particularly pathological  
case. For simple cases, a "paid upgrade" flag in the appcast is all  
that's required: we just notify users that there is an update, but it  
requires a paid upgrade. The thing is, we ideally want to get them  
going through the license process, then download the update. We don't  
want to just download it when they click "visit the site to buy the  
license", because then if they decide not to, they're screwed. We also  
don't want to make them download the update manually, because that's  
so 2005.

More likely, since every uses difference licensing systems and simply  
directing users to the app homepage probably isn't sufficient for many  
cases, I'll have an application delegate protocol through DO, and I'll  
let the app do the logic for whether the update will require a new  
license (so Snak will work), and I'll let it deal with presenting the  
upgrade UI and letting Sparkle know when the upgrade is complete so it  
can continue the download.

For people who just use web sites for license purchases, one solution  
would be to put a sparkle:// link on the "thanks for the purchase!"  
page.

- Andy Matuschak

On Aug 4, 2007, at 8:11 PM, David Symonds wrote:

> On 05/08/07, Andy Matuschak <andy at andymatuschak.org> wrote:
>>> I'd suggest using posets to represent version changes, which could  
>>> be
>>> encoded fairly compactly in an appcast, so the whole clunky
>>> version-guessing-game can be almost completely removed.
>>
>> Can you give me an example of how you see this working? Another issue
>> is the UI for selecting which branch to be on. If there's a simple
>> list of branches, we could just have a default branch and then  
>> options
>> in the prefpane. But posets aren't that simple. Also, it'd be nice to
>> be able to give the developer some control somehow over access to
>> difference branches.
>
> There are two issues:
>  (1) representation of the relationships between releases (of any  
> kind)
>  (2) the semantics of the structure of those representations
>
> I'm learning to use git at the moment, and it's shaped a bit of my
> thinking about this, so here's my initial take on (1), above:
>
> Let's take the fictional "MyApp", which has a successive linear set of
> initial releases, with versions 0.1, 0.2, 0.99b1, 1.0rc1, and 1.0. We
> can represent those as elements of a poset
> (http://en.wikipedia.org/wiki/Poset):
>
> MyApp 0.1 < MyApp 0.2
> MyApp 0.2 < MyApp 0.99b1
> MyApp 0.99b1 < MyApp 1.0rc1
> MyApp 1.0rc1 < MyApp 1.0
>
> Or, more compactly:
>
> MyApp 0.1 < MyApp 0.2 < MyApp 0.99b1 < MyApp 1.0rc1 < MyApp 1.0
>
> So far so good, though it already has the benefit of not needing any
> fancy version comparison functions, so the developer can use any wacky
> versioning system he wants. Now, imagine he starts working on version
> 2.0 with some beta testers, but keeps making minor revisions of 1.0.
> Here we get a divergence from the strictly linear version ordering:
>
> MyApp 1.0 < MyApp 1.1 < MyApp 1.2 < MyApp 1.3
> MyApp 1.0 < MyApp 2.0b1 < MyApp 2.0b2 < MyApp 2.0b3
>
> Eventually, MyApp 2.0 will be ready for release, so the developer can
> mark it as superseding MyApp 1.3, as well as the final beta version:
>
> MyApp 1.3 < MyApp 2.0
> MyApp 2.0b3 < MyApp 2.0
>
> At this point, we get a nice diamond shape, or two parallel tracks
> ("branches"). If you excuse my crummy ASCII art:
>
>                    MyApp 1.1 < MyApp 1.2 < MyApp 1.3
> MyApp 1.0 <
>        < MyApp 2.0
>                    MyApp 2.0b1 < MyApp 2.0b2 < MyApp 2.0b3
>
> As for (2), each of these branches could be labelled easily enough,
> and a requirement could be made to mark one as the "default" branch,
> which can easily be propagated through the poset, etc.
>
> Thoughts?
>
>
> Dave.
> _______________________________________________
> 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/20070805/eb88f685/attachment.htm