[sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
> I'm not sure this satisfies me.  It might accurately handle the use case of
> updating when upgrading, assuming that activity developers are very careful
> to add extra info about compatibility into the .info file.  It doesn't
> however, make it easy to decide what version of an activity to download if
> I've never used it before, and I'm not on the most recent release of Sugar.

No, this problem is already solved by the scheme I outline.

> I agree with the signature approach.  However, I don't really know what
> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and
> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to
> coincide with the "level of newness".  This is something we will lose
> completely without a minor release number.  The logical assumption is that
> "the bigger the number, the better/newer it is", which is blatantly false
> when point releases are intermixed with brand new versions with
> ever-increasing version numbers.  I might decide I need to clear up space,
> and so delete versions 37 and 38, thinking I was keeping the latest and
> greatest version 39 and be quite disappointed.

I don't see how your solution solves this problem either.  Say the
activity author has released 0.4, 0.6, 1, 1.2, and 1.3.  Versions 0.6,
1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version
0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that
was broken in the 8.2 update, and 1.2 didn't have the bug introduced
in 1.3).  What's the "level of newness"?

Sadly, I think that it's up to the activity authors to ensure that
newer versions work on older releases.  I admire your desire to make
more powerful version numbers, but simply adding an extra digit isn't
going to materially change anything.

I think the most interesting question is "what's the newest version
compatible with my release", and that's the problem I've solved.  I
agree that it would be interesting in the future to be able to mark
activities in the activity list that "can't possibly be expected to
run" for some reason or another (like an API incompatibility), but I
don't think I agree that manually putting information in an
activity.info file is the best way to do that -- for starters, the
information you'd like to add all have to find its way into that file
*retroactively* after the new release has come out which is
incompatible.  A better method would be to provide a standardized way
for a python app to run code which performs tests and returns a
go/no-go, or else to just mark activities which fail during launch.
  --scott

-- 
 ( http://cscott.net/ )