[Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)
tomeu at sugarlabs.org
Thu Mar 19 06:05:50 EDT 2009
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?
More information about the Sugar-devel