[Sugar-devel] [IAEP] Activity version compatibility

Wade Brainerd wadetb at gmail.com
Fri Oct 16 22:35:02 EDT 2009


On Tue, Oct 13, 2009 at 6:15 PM, Gary C Martin <gary at garycmartin.com> wrote:
> On 13 Oct 2009, at 15:29, Tomeu Vizoso wrote:
>
>> On Wed, Sep 30, 2009 at 05:35, Wade Brainerd <wadetb at gmail.com> wrote:
>>>
>>> BTW, we should still answer the question of the activity.info field...
>>>  Seems like there 3 options to me:
>>> 1) Deprecate host_version in the activity.info spec.  Activity developers
>>> write code to test for presence non-BC APIs and provide fallbacks (or
>>> else
>>> let activities fail to launch/work).
>
> FWIW 1) is the one I've been following (testing for available features,
> providing fallbacks, accept failure to launch reports as bugs to fix). It
> seems to just be a small number of current Sucrose activities that are
> genuinely backwards incompatible with previous Sugar releases.
>
>>> 2) Keep host_version as an incrementing number, make activityfactory
>>> respect
>>> it, and bump the Sugar number from 1 to 2 in 0.86.1 to reflect the
>>> toolbar
>>> changes.
>>> 3) Deprecate host_version, introduce sugar_version which is set to the
>>> oldest Sugar version number the activity is compatible with.
>
> I'd not object to 3) if someone really has a bee in their bonnet ;-b but I'd
> be unlikely to use it, and don't see it helping in many real user cases (it
> just provides an opportunity to show a prettier error message). Sugar
> platform releases seem pretty far down the scale of reasons for most launch
> failures, 95% of such cases will be covered by a smarter pulsing-window
> launcher for when an Activity fails (bad distro installs, latest
> architecture flavour of the week, missing platform dependancies, new changes
> in Sugar that break old code, un-anticipitated security permissions, actual
> bugs, users hacking on and breaking code).
>
> Regards,
> --Gary

I'm also in favor of 1) as a starting point.  I will submit a patch to
remove all references to host_version and remove it from the
documentation.

If in the future we realize we need something better, we could talk
about 3) again.  Totally agree w.r.t. most activity failures.

-Wade


More information about the Sugar-devel mailing list