[Sugar-devel] Activity version compatibility

[Art Hunkins]

----- Original Message ----- 
From: "Gary C Martin" <gary at garycmartin.com>
To: "Wade Brainerd" <wadetb at gmail.com>
Cc: "sugar-devel Devel" <sugar-devel at lists.sugarlabs.org>
Sent: Monday, September 28, 2009 3:42 PM
Subject: Re: [Sugar-devel] [IAEP] Activity version compatibility


Hi Wade,

On 28 Sep 2009, at 13:26, Wade Brainerd wrote:

> Hey Bert,
>
> I wasn't aware of host_version - it looks like it's supported for
> content bundles, with any value other than 1 (hardcoded) raising a
> MalformedBundleException.  It's ignored for activity bundles.  So
> basically it was written into the spec and then dropped.
>
> I suppose we could resurrect host_version, or else add the new
> field.  I'm open to either avenue.  (Though I feel like just using
> the Sugar version as the value would be simpler than maintaining an
> independent version number)

My main concern is, "how will most developers know what versions of
Sugar their activity will work under?" This is going to be an ever
growing .info string that will need constant maintenance once added.
Will it be a white list of sugar versions, a black list of sugar
versions, a combination of both, with omissions assuming it works, or
fails?

So we end up with something like this in the .info that we may need to
update on every release:

host_version = +0.82; -0.83; +0.84; +0.86

If we only have this detection back ported for 0.84 and 0.86 I guess
the 0.82 is irrelevant even though that's what the majority of Sugar
users are currently using. I'd be likely to leave this line out and
accept any bug reports as feedback for 'please fix your activity to
work with this version of Sugar'.

I'd much rather put the effort into fixing the launch pulsing window,
so it is not so stupid. It needs to recognise when a process failed to
start, and, at the very least, exit quickly back to the rest of the UI.

It could (at a later date) be extended to do something smart with the
fail case; report the error to the user somehow – nice pretty error
graphic, the original mac bomb icon was a legend in its time, perhaps
a large bug icon [1] for 5 seconds ;-) – rather than just 'not
starting'; the UI could potentially lead folks to the crash log, or
just allow revealing the last traceback (if found) for manual
reporting (or debugging); the UI could potentially allow (only if
connected to the internet) the bug to be automatically posted back to
SL/developer for some automatic data mining to help decide which fail
cases folks hist most.

[1] I cleaned up Walters TA bug icon for use in the new Log toolbar,
but it didn't make it in this time around 
http://wiki.sugarlabs.org/go/File:Toolbar-bug.png

Sorry to be seeming to rain a little on the idea of release version
checking, but I'm not sure most developers will ever fill this out
correctly, and we're better of just being smarter about catching
Activity (start-up) tracebacks quickly. And happy to help in this area
if folks think this a good direction.



Yes. IMO, this is the right direction.

And yes, all developers should be strongly encouraged to make their 
activities work on as many versions of  Sugar as possible.

At the same time, it would behoove system developers to keep their 
improvements/enhancements when possible from "breaking" established code. 
(Activity developers have better things to do.)

Art Hunkins


Regards,
--Gary

> -Wade
>
> On Mon, Sep 28, 2009 at 7:43 AM, Bert Freudenberg <bert at freudenbergs.de
> > wrote:
> (moving to devel list)
>
> I thought that's what host_version is for?
>
> - Bert -
>
>
> On 28.09.2009, at 02:40, Wade Brainerd wrote:
>
> Tentative patches posted to http://dev.sugarlabs.org/ticket/1442.
>
> An Alert when attempting to install the .xo bundle would be really
> nice, but this at least prevents the activity from appearing in the
> list.  It also adds the raw data, which could be displayed in the
> bundle's metadata.
>
> -Wade
>
> On Sun, Sep 27, 2009 at 7:13 PM, Wade Brainerd <wadetb at gmail.com>
> wrote:
> This might be a good time to introduce an optional
> "sugar_version=..." field into activity.info, so we can display a
> human readable error message when this mistake happens.  The
> activity will not launch unless Sugar's version is greater than or
> equal to the activity.info field.  Most activities will not need it,
> but in case of using non-backwards compatible APIs it will be handy.
>
> Is this too big a change to patch 0.84 and 0.86 with?  It will take
> at least two releases before it can have any real benefit.
>
> Regards,
> -Wade
>
> On Sat, Sep 26, 2009 at 10:15 PM, Gary C Martin
> <gary at garycmartin.com> wrote:
> Hi Gerald,
>
> Many thanks for the feedback.
>
> On 27 Sep 2009, at 02:52, Gerald Ardito wrote:
>
> > Gary,
> >
> > This image came from Caroline Meeks at Solution Grove. It came as
> > part of a version of SOAS that she put together for me.
> >
> > Gerald
>
> OK, looks like a SoaS build mistake.
>
> Caroline, just a quick ping. Checking activities.sugarlabs.org, it
> tells me Write-63 was the last version compatible with Sugar 0.84.x. I
> believe Aleksey started working on the new 0.85.x toolbar code as of
> version 64, breaking compatibility with earlier versions of Sugar:
>
>      http://activities.sugarlabs.org/en-US/sugar/addons/versions/4201
>
> Regards,
> --Gary
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
> _______________________________________________
> 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