[Sugar-devel] Activity Versioning - Dotted Scheme

Wade Brainerd wadetb at gmail.com
Sun Nov 29 13:23:22 EST 2009


A problem with introducing dotted version numbers is that Sugar
versions 0.82-0.86 parse the activity version field using the Python
int() function.

>>> a = int('100.3')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '100.3'

If we introduce periods into activity version strings, Sugar will
throw a MalformedBundleException when parsing activity.info.  The
effect would be that Sugar would simply fail to register the activity;
it would not appear in the Home view etc.

So, introducing period syntax into an activity bundle automatically
makes it incompatible with Sugar versions 0.82 - 0.86.
This is too harsh for me, so like Gary I would just keep using integers.

On Tue, Nov 24, 2009 at 8:54 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
>> Yes, good point. We should revisit the current activities in Fructose
>> and think if it makes sense to keep them in Fructose. As you said, one
>> point is if an activity has dependencies on the platform itself like
>> Browse (Hulahop).

Has anyone looked into what would be needed to just make Browse work
with older versions of Hulahop?

Anecdote: My XO ran out of space over Thanksgiving and automatically
deleted Browse at boot time.  I downloaded the latest version, but it
failed to launch as my XO is running the OLPC 8.2.0 build.  This was
pretty annoying to me as I didn't have a web browser available to go
find out which version *would* work.

> In mind thats wrong way, some activities have non-sugar SP dependencies
> and can work fine with several SP releases, I guess its better to not add
> additioanl complexity and use only one source for compatibility info -
> on ASLO(moreove we have fructose activities on ASLO).

+1 to keeping activity version numbers totally separate from SP version.

> BTW for 0.88 can exclude fructose from core packages at all and let
> deployers decide what should be included to deployments.

I support this - ASLO works well enough that Fructose isn't strictly needed.

Wade


More information about the Sugar-devel mailing list