Re: [Sugar-devel] [IAEP] Activity version compatibility

[Gary C Martin]

Hi Wade,

On 28 Sep 2009, at 21:59, Wade Brainerd wrote:
On Mon, Sep 28, 2009 at 3:42 PM, Gary C Martin  
<g...@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.

Hmmm. So what happens when Sugar depreciates some API and breaks old  
activities? Say in a year or so when the core folks decide to remove  
the old toolbar API code? Or perhaps some of Telepathy and its API  
which is getting rather overdue for a fix'er'upper effort?

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

See this is where I'm at. I'm very tempted to go back and add the old  
toolbar support back into Write (I already did this for Calculate and  
it's not too painful, working on the same for Labyrinth just now). The  
core devs don't think this is worth the effort, because they want  
folks to move up to newer versions of Sugar (and get to use all the  
great new features they have worked on), but the Activity developers  
also want their activities to be a maximum benefit right now, which  
means supporting 0.82 for the ~98% of our user base right now.

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.

Cool :-)

[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?

Sure go for it, here's the SVG:

<<inline: toolbar-bug.svg>>
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.

If it's just for developers that want to specifically warn that their  
activity won't work. Why not let them just pop in a try/except around  
the sensitive API and show an alert within their Activity? If they  
already know enough to know it will fail, they'll know where and why.

Regards,
--Gary

_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel