[Sparkle] Thinking about unifying Sparkle...

[David Symonds]

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.