On Fri, Mar 13, 2009 at 20:17, David Farning <dfarn...@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 <wad...@gmail.com> wrote: >> On Wed, Mar 11, 2009 at 1:17 PM, Eben Eliason <e...@laptop.org> wrote: >>> On Wed, Mar 11, 2009 at 1:05 PM, Wade Brainerd <wad...@gmail.com> wrote: >>>> On Wed, Mar 11, 2009 at 12:05 PM, Tomeu Vizoso <to...@sugarlabs.org> wrote: >>>>> On Wed, Mar 11, 2009 at 17:00, Eben Eliason <e...@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/de...@lists.laptop.org/msg11149.html >>>>>> http://www.mail-archive.com/su...@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@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel