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

[Tomeu Vizoso]

On Fri, Mar 13, 2009 at 20:17, David Farning <dfarning at sugarlabs.org> wrote:
> 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.

The biggest difference I see between Eclipse plugins and Sugar
activities is that we would like users to modify activities and
redistribute them. That brings some more complexity to the matter.

Regards,

Tomeu

> 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
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>