Activity versioning schema

[Eben Eliason]

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

> 2008/7/14 Eben Eliason <eben.eliason at gmail.com>:
> > There was an extensive discussion on this topic a while back on IRC,
> which I
> > unfortunately don't have a record of.  There was also mention of this in
> the
> > mailing lists not too long ago, initiated by
> > Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html.
> >  Finally, I brought this up at the end of a recent tech team meeting (1
> or 2
> > weeks ago?) as a topic that needed our attention in order to make the
> > update/upgrade system work (specifically, regarding the need for minor
> > versions so that we can make bugfixes to older versions of an activity
> (say,
> > 4.x) while keeping 5.x for all versions that work with the next version
> of
> > the OS).  I think deciding how we version activities is a critical part
> of
> > making our OS releases work, and can assist in the problem of answering
> > "Which activities work with my release?".  Answering 4.x is nicer than
> [34 -
> > 42], and MUCH nicer than [36-38, 40, 42].
> > The "agreement" I speak of was really a lack of any voiced disagreement
> when
> > I mentioned this issue at the meeting.
>
> From extensive auditing of current activity version numbers:
>  a) a large number of activities are using completely random and bogus
> strings for their version numbers.  "Just an integer" is about the
> simplest possible scheme, and people still don't get it.  I'm
> unconvinced that any more complicated scheme will work better.


They don't get it? Or they don't get how a single integer is supposed to be
sufficient, and therefor use their own methods?  Do you have examples of
specific "random and bogus" strings we can look at to see what's been tried?

>
>  b) There is an alternative mechanism already in place for handling
> dependencies on specific versions, documented in the [[Activity
> bundles]] entry for 'update_url'.  Basically, you can specify a
> different version number as appropriate based on the current OS build,
> release version, and release major version.  So you can say, "version
> 8 if you are using 8.1, or version 9 if you are using 8.2".


How does this actually help the user, or the tech support team when someone
wants to know "what version of chat works with 9.1.0?"  Short of saying
"Well, the system will (should) know if it can support an activity, so
download it and see..." what do we have?  We say "Well, versions 36-38, and
also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes
for 8.2".  This seems silly to me.  Just say versions 4.x and 5.x work with
8.2 and 6.x works with 9.1.  This also makes displaying multiple versions
(activity "threads") possible in the OS.  Otherwise how can we reasonable
sort/group the activities in any way that makes sense?

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