Activity versioning schema

C. Scott Ananian cscott at
Mon Jul 14 16:09:59 EDT 2008

On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <eben.eliason at> 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 = ''
>>> 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", 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

This is under-reported, since many of the bad activities just set

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

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

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.  There is an additional grouping mechanism in
the updater, as well, that lets countries define things like "G1G1
activities" or "Peru activities".

 ( )

More information about the Devel mailing list