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

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:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: toolbar-bug.svg
Type: image/svg+xml
Size: 11527 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090929/f4e13de7/attachment.svg 
-------------- next part --------------

> 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