[Sugar-devel] 0.84 maintenance
simon at schampijer.de
Mon Dec 7 05:16:31 EST 2009
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?
I think it is absolutely fine to break backwards compatibility at one
point. Similar to the API policy , 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?
More information about the Sugar-devel