[Sugar-devel] 0.84 maintenance
walter.bender at gmail.com
Mon Dec 7 03:05:02 EST 2009
Christian is in the process of pulling together an inaugural edition
of the Sugar Journal. It will include articles teachers, developers,
etc. It would be nice to include some representation from the activity
team. I was think of two different types of articles: a featured
activity, where there is a chance to go into detail about one
activity--how it works from both the user and developer
perspectives--and perhaps some tips for developers--how to use this
widget or achieve that goal...
In regards to the former, perhaps we can feature one of the activities
that is getting a lot of classroom use, to highlight how an activity
can enhance learning; in regard to the latter, how about an article
about maintaining backward compatibility? (A seemingly timely topic.)
On Sun, Dec 6, 2009 at 7:26 PM, Wade Brainerd <wadetb at gmail.com> wrote:
> On Sun, Dec 6, 2009 at 6:26 PM, Walter Bender <walter.bender at gmail.com> wrote:
>> On Sun, Dec 6, 2009 at 6:20 PM, Gary C Martin <gary at garycmartin.com> wrote:
>>>> 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).
> Yeah, that's my feeling as well.
>> 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.
> Aleksey's sugar-ports  library helps mitigate this for me. You
> just copy modules such as json, toolbar, objectpicker, etc. from
> sugar-ports into your activity and use them instead of the native
> Sugar APIs.
>> 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?
> Agreed - Though, as long as users are getting activities via ASLO,
> hopefully they are using the Support links when things are broken.
>  http://git.sugarlabs.org/projects/sugar-port
More information about the Sugar-devel