[Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
wadetb at gmail.com
Thu Mar 19 13:06:57 EDT 2009
On Thu, Mar 19, 2009 at 6:05 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Wed, Mar 11, 2009 at 18:34, Wade Brainerd <wadetb at gmail.com> wrote:
>> On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason <eben at laptop.org> wrote:
>>> On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd <wadetb at gmail.com> wrote:
>>>> On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>>>> On Wed, Mar 11, 2009 at 17:00, Eben Eliason <eben at laptop.org> wrote:
>>>>>> Here is some (OK, a lot) of background reading on the subject. I
>>>>>> still cast my vote for a major/minor distinction, as mentioned in my
>>>>>> response on the second thread below.
>>>>> That's also my favorite right now.
>>>> I actually have the exact opposite instinct, coming at it from the
>>>> user's perspective. The best choice for *users* is to keep the
>>>> linearly incrementing version, and document which activity versions
>>>> work with which Sugar versions. The activities.sugarlabs.org system
>>>> already has an easy way to see what application versions an activity
>>>> version works with.
>>>> We should strive to ensure that newer versions of activities will work
>>>> with older versions of Sugar or else fail gracefully. Eben's idea to
>>> I think this might be a big assumption to make. Sugar could include
>>> new libraries at some point. We could add additional classes and
>>> controls to the toolkit. There could be a fundamental change in the
>>> protocol for some activity or service. Obviously we'd prefer to keep
>>> backward compatibility, but can we promise it always and indefinitely?
>>>> show activity startup failure information on the launcher screen would
>>>> help a lot with the "fail gracefully" part.
>>> If we wait until activity launch to inform the user a particular
>>> activity won't work for them, we'd better be quite certain that it's
>>> easy to revert the update.
>>>> Being able to "branch" activities would perhaps help the Sugar
>>>> development team. But for the users, in this situation it would be
>>>> best to make a new Terminal 25 that works with 0.86 and 0.84, and then
>>>> update 0.84 to reference that.
>>>> Think about it this way- someone with 0.84 can go *right now* and
>>>> download Terminal v24 or later. So why can't we just update 0.84 to
>>>> reference Terminal v24+ if a bug is found in v23?
>>> This could be ideal if every newer version will always work with older
>>> versions of Sugar. Consider, though, that some bugs might only exist
>>> on older versions of Sugar. Would we want to push an update to
>>> everyone for this?
>>> Also, it still seems clearest to me to be able to make statements like
>>> "versions 21–23 of Terminal work on 0.84 and version 24 works on 0.86"
>>> (where versions have one or more implicit .x minor versions). With the
>>> major-version-only approach (and assuming we don't have full backward
>>> compatibility), we have to resort to statements like "versions 21–23
>>> and also 25 work on 0.84, and versions 24 and 26 work on 0.86."
>>> - Eben
>> Ultimately I think this all comes down to putting the responsibility
>> for stability and compatibility on the developer instead of the user.
>> As soon as we add those minor numbers, people's eyes will glaze over
>> and the support emails will start rolling in :)
>> If the Sugar developers are responsible about keeping the API
>> compatible, and if Activity developers are responsible about
>> responding to bug reports and maintaining compatibility, the situation
>> you are describing will not happen. Generally speaking we are talking
>> about theoretical exceptions here anyway - I can't think of a
>> situation where it's actually happened, except perhaps with Browse
>> whose code I argue should be part of the Sugar toolkit anyway.
>> Consider that some stupid DOS program I wrote back in 1995 still works
>> just fine on the Windows 7 Beta - that's some impressive binary
>> compatibility. We don't have to go that far, we just have to maintain
>> the DBus protocol for C (and eventually other) activities and the
>> Sugar toolkit API for Python activities.
> I think this is perfectly doable, but will take substantial testing
> and coding effort to reach the goal of backwards compatibility. And
> right now I don't see those resources available.
> We have few people working on the Sugar core but a lot of activity
> authors. May be wiser to move that responsibility from the development
> team to the activity team?
Yes, that's absolutely fine with me. We already work around
differences in things like Python version all the time. It's just a
matter of building up our bag of tricks and making sure it's applied
More information about the Sugar-devel