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

[Wade Brainerd]

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