[Sugar-devel] 0.84 maintenance

[Simon Schampijer]

On 12/07/2009 12:26 AM, Walter Bender wrote:
> On Sun, Dec 6, 2009 at 6:20 PM, Gary C Martin<gary at garycmartin.com>  wrote:
>> Hi Tomeu,
>>
>> On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote:
>>
>>> 2009/12/1 Daniel Drake<dsd at laptop.org>:
>>>
>>>> Also on this topic - we will certainly run into issues where activities
>>>> themselves progress beyond the Sugar-0.84 platform; if activity authors
>>>> could work to minimize these cases (i.e. keep backwards compatibility,
>>>> remain responsive to bugs) it would help us avoid a huge headache, and
>>>> will help your activities spread to various corners of the globe.
>>>
>>> I think this is a current policy of the activity team?
>>
>>
>> The word policy seems a little official, but yes, I'd certainly not want one of the activities I help maintain to intentionally break under 0.84 (or 0.82 for that matter).
>
> On the other hand, it is getting to be more and more difficult as an
> activity developer to keep on top of all the details necessary to
> maintain backward compatibility. The toolbar is one thing--but changes
> to journal interactions, json, rainbow, drivers, etc. are less
> easy--for me--to juggle. However, testing is probably the biggest
> issue. Not sure what the best course of action is--perhaps any large
> deployment that is running an old Sugar could assign a testing team to
> that version to provide feedback to activity developers?
>
> -walter

I think it is absolutely fine to break backwards compatibility at one 
point. Similar to the API policy [1], when deprecate parts, backwards 
guarantee I would just ensure for a certain amount of time.

For example the toolbars introduced in 0.86 was a major turning point to 
me. There could be a category pre 0.86 and post 0.86. The latest 0.84 
version should be backward compatible and get bug fixes and the latest 
development (0.87) should work on 0.86, too. Two versions to maintain - 
I think that is doable.

Of course this would mean new features that gets written for the latest 
version won't get into the old version (unless you backport them). That 
is a trade-off, to me this looks ok.

In any case - even if you write your latest activity compatible for 
0.82, the kid running Sugar still needs to update to that version. Are 
there numbers how often that really happens?

Regards,
    Simon

[1] http://wiki.sugarlabs.org/go/Development_Team/API_policy