[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