Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 5:34 PM, C. Scott Ananian <cscott at laptop.org> wrote:

> 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.


Can you explain how?  For instance, if I'm looking at a wiki page for an
activity, how does that page tell me which version I need?  How can a
tech-support guru tell the person on the other end of the line what they
need?  It seems your approach only works when software is working it's magic
on the extra info in the .info file.

>
>
> > 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"?
>

I still think it mostly solves it.  You're confusing "newer version of an
activity" with "runs on newer version of OS", I think.  For instance, even
though 0.4 runs on 8.2 because it didn't use some new feature of 8.1 doesn't
make it any newer.  It's still old, less mature code, and the UI and feature
set would certainly back that up.  The bugfixes in 1.2 might also make the
activity work on both 8.1 and 8.2, but that doesn't change the fact that the
fixes were still to a version of the activity less mature than 1.3, and
likewise containing fewer features.

Most importantly, you've demonstrated that the "natural ordering" of the
versions is 0.4, 0.6, 1.2, 1.3, which is true regardless of the fact that
1.2 might have been released months after 1.3.  The level of newness seems
intact to me.

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 you're wrong.  I think that exposing single digit version numbers
is, subconsciously or not, going to indicate to them that the largest number
is the newest version of the activity.  The problem is that the definition
of newest isn't in sync with expectation.  It's only newest in that it was
released most recently, but that's not what really matters.  What matters is
which of them is the most mature in terms of code/features.

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


Again, I disagree.   Take, for instance, your example from above. It was
clear that both versions 1.2 and 1.3 work on 8.2.  If 1.2 was released after
(temporally) 1.3, it's technically "newer" and would have a higher version
number (in the old scheme).  It's also compatible with 8.2.  So the newest
version compatible with my release is therefore 1.2, even though there's
actually a newer-as-in-features 1.3 release that I'm really after.

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


What?  All I'm suggesting is a minor version number.  Nothing needs to be
added retroactively to existing activities.  We can just assume that absence
of a minor version means that it's X.0 instead.

>
> 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
>

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/7eab4a79/attachment.html>