Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <jquinn at cs.oberlin.edu>
wrote:

>
> 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.
>>
>> - Eben
>>
>
> This idea works well when developers time their new-features releases to
> coincide with Sucrose updates. It starts to break down when that does not
> hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds
> essentially the same feature-set as 3.0" or some combination of both? I
> think that Eben is assuming the former - that nobody would go back and
> release lower version numbers except in order to maintain system
> compatibility - but this conflicts with a common assumption that major
> version changes are synonymous with major new features.
>
> Basically, there are two separate problems here, and we should not be
> solving them together. One is that the latest release may not be the
> greatest - because of bugfix releases. I agree with Eben's proposal of minor
> version numbers as a (totally optional) solution; as long as the minor/major
> separator is not a decimal separator (that is, [.,]), the meaning is pretty
> self-evident. (I think that : is the best candidate, by analogy with times
> and bible verses.)
>

This is actually my primary concern.


> But the second problem is harder: how do you tell people which versions run
> on which Glucose. Any attempt to encode this implicitly in version numbers
> is, I think, bound to fail, and not too helpful anyway. The update_url
> solution for #4951 fixes the most useful version of this problem - "what is
> the latest working version on my system". I think we can live without a more
> general solution to "will version X run on system Y" - even though that
> means some ugly trial-and-error when sharing activities across Glucose
> versions.
>

I don't expect to have any encoded info which makes this decidedly easy.  I
just want a simple way to say that versions 3.x - 5.x work on  OS release
8.2.  Nothing in the bundle needs to indicate that specifically, but at
least we'd have a way to easily document compatibilities. I understand what
you mean in that activity cycles won't necessarily match OS cycles, and it's
true.  It's possible for several releases to be "designed for" a single OS
version, and likewise possible that a major activity version would span
several OS versions.  I'm mostly trying to safegaurd against the possibility
of future API or other incompatibilities which come from Sugar itself.  It
would be up to the activity developer to decide if they wanted to jump to a
new major version to support a new API or feature which isn't around in
older versions of the OS.

- Eben


>
> ...
>
> and cscott just wrote an email which says many of the same things.
>
> Jameson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/c4a1306b/attachment.html>