Activity versioning schema

[Jameson "Chema" Quinn]

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

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.

...

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/14e7c80d/attachment.html>