[Sugar-devel] [IAEP] Activity version compatibility

[Wade Brainerd]

On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin <gary at garycmartin.com> wrote:

> My main concern is, "how will most developers know what versions of Sugar
> their activity will work under?" This is going to be an ever growing .info
> string that will need constant maintenance once added. Will it be a white
> list of sugar versions, a black list of sugar versions, a combination of
> both, with omissions assuming it works, or fails?
>
> So we end up with something like this in the .info that we may need to
> update on every release:
>
>        host_version = +0.82; -0.83; +0.84; +0.86
>

In the patch I posted, I assume that activities pick the oldest version of
Sugar they are compatible with.  For example, new Toolbar classes were
introduced in 0.86, so the latest Terminal will write:

host_version = 0.86.0

If you are a lazy activity developer, you simply write the version that you
tested the activity for.   There is no + or -, since we assume that Sugar
will not break old versions of activities with new releases.  This is not a
new concept; we have always had the monotonically incrementing host_version.
 It's just never been incremented (or properly supported) before.

I arrived here from a pragmatic place: I cloned Terminal from Gitorious and
realized it doesn't launch on my version of Sugar (SoaS Strawberry).  I
briefly looked into fixing it, but didn't see the immediate way to do that.
 That left me with two options:

1) Do the work to maintain backwards compatibility
2) Accept that users will experience crashes

I'd much rather have a third option, especially if we plan to make further
additions to the sugar toolkit along the lines of the new toolbars.
 (Aleksey's sugar-ports library does go a long way towards making 1 easier -
way to go!)


> I'd much rather put the effort into fixing the launch pulsing window, so it
> is not so stupid. It needs to recognise when a process failed to start, and,
> at the very least, exit quickly back to the rest of the UI.
>

I have a prototype patch which fixes the launch window and adds an error
message.  I'll try to get it posted soon.


> [1] I cleaned up Walters TA bug icon for use in the new Log toolbar, but it
> didn't make it in this time around
> http://wiki.sugarlabs.org/go/File:Toolbar-bug.png


Awesome!  Mind if I use this in
http://wiki.sugarlabs.org/go/Features/Problem_Reports?


> Sorry to be seeming to rain a little on the idea of release version
> checking, but I'm not sure most developers will ever fill this out
> correctly, and we're better of just being smarter about catching Activity
> (start-up) tracebacks quickly. And happy to help in this area if folks think
> this a good direction.
>

I agree that it's not likely that developers will fill it out consistently,
but at least they don't ever need to if they don't care about it.  It's just
a way for activity developers like me who want to inform users that their
activities have a limit w.r.t. backwards compatibility.

Best,
-Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090928/9e28615d/attachment-0001.htm