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

[Eben Eliason]

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
>