[sugar] Activity versioning schema

[Eben Eliason]

Comments follow...

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

> On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
> > 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?
>
> On an XO:
> $ python2.5
> >>> act_page = 'http://wiki.laptop.org/go/Activities'
> >>> import urlparse, re, urllib
> >>> import bitfrost.update.actutils as actutils
> >>> urls = [urlparse.urljoin(act_page, url) for url in
> re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if
> url.endswith('.xo')]
> >>> for u in urls:
> ...   try:
> ...     cp = actutils.activity_info_from_url(u)
> ...   except:
> ...     print "BAD activity.info", u
> ...     continue
> ...   if not cp.has_option('Activity','activity_version'):
> ...     print "MISSING VERSION", u
> ...     continue
> ...   try:
> ...     pass
> ...   except: pass
> ...   v = cp.get('Activity','activity_version')
> ...   try:
> ...     assert not v.startswith('0')
> ...     assert not '.' in v
> ...     v = int(v)
> ...   except:
> ...     print "BAD VERSION", u, v
> ...
> MISSING VERSION http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo
> BAD activity.info http://wiki.laptop.org/images/7/7e/Gmail-2.xo
> BAD activity.info http://opteron.9grid.us/olpc/inferno-012808.xo
> MISSING VERSION http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo
> BAD activity.info http://www.linuxuser.at/dl.php?i=ImageQuiz.xo
>
> This is under-reported, since many of the bad activities just set
> activity_version=1:
>
> >>> def bad_ver(v):
> ...   try:
> ...     assert not v.startswith('0')
> ...     int(v)
> ...     return False # good
> ...   except:
> ...     return True
> ...
> >>> vers = [v for v in re.findall(r'<span
> class="olpc-activity-version">([^<]*)</span>',
> urllib.urlopen(act_page).read()) if bad_ver(v)]
> >>> vers
> ['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',
> '012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',
> '080601', '080601', '080601', '080601', '080601', '080601', '080601',
> '080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',
> '\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']
> >>>
>
> >>  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
>
> Just say, "does the activity updater show an update for your version
> of Chat? if so, install it, please."
>

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.
 What if I still have 8.1 even though 8.2 is out, and I find a cool new
science activity I want.  What version to get?  Well, maybe 23.  Maybe 32.
 Maybe 24-31 are all incompatible because of a new API in 8.2, but how would
I know?  Is the best suggestion to download a really old version and then
wait for it to inform me of an update?


>
> The alternative is not going to work, because the activity authors
> can't keep their bundle ids straight, much less collectively agree to
> use release-synchronized version numbers in a sane way. You are
> proposing a more complicated system, which just introduces more ways
> to go wrong w/o actually addressing any part of the real metadata
> problem.


So make the requirements more strict.  Don't run/install a bundle unless it
adheres to the format.  We should be doing that anyway.  Develop can easily
handle a major/minor revision checkbox to keep things in sync with little
overhead for those that care and NO overhead for those that don't (let them
ignore the possibility of minor releases; it won't break things).  The
major-version-number-only approach is a valid subset of a major-minor
approach.

Moreover, I'm not sure what's going on with many of these version numbers.
 Those of the form 080601 seem to be using dates.  OK, that's wrong.  I have
no idea what the x90 type of versioning is about, but there are so many it
seems there must be a single developer/group using that in a bunch of their
own activities, which makes it an endemic and not an epidemic problem.  The
remainder of them seem to be well formed major.minor numbers (minus a few
which append "beta" unnecessarily, since as Brian noted previously using 0
as the major version number can satisfy that).

As regard to sorting/grouping: we already discussed that at our last
> mini-conference:  simple ordering by version number, with group breaks
> when signature changes.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080714/73f992f6/attachment-0001.htm