[Sugar-devel] Activity Versioning (Was Re: [RELEASE] Terminal v24)

[David Farning]

One project to look for on how to handle activity versions is eclipse.
 The notion of the eclipse plug-in ecosystem is virtually the same as
it is in Sugar Labs.

Eclipse has a few years of struggling with this issue under their belt.

http://www.eclipse.org/equinox/documents/plugin-versioning.html
http://wiki.eclipse.org/index.php/Version_Numbering

david

On Wed, Mar 11, 2009 at 12:34 PM, 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.
>>>>>
>>>>> http://www.mail-archive.com/devel@lists.laptop.org/msg11149.html
>>>>> http://www.mail-archive.com/sugar@lists.laptop.org/msg03283.html
>>>>
>>>> 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
>>
>>
>>> Regards,
>>> Wade
>>>
>>
>
> 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.
>
> -Wade
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>