Reject activity bundles which require a newer version of Sugar

[wadeb]

Currently, there is no error checking mechanism for activities which require newer versions of Sugar. They will install correctly but then fail to launch.

These patches for sugar-toolkit and sugar add a new sugar_version field to activity.info which indicates the minimum required version of Sugar to run the activity.

I guess they would probably backport well into 0.86 and 0.84 as well.

These patches are just the first step. In addition, an Alert should be shown when resuming an activity bundle (.xo file) whose version is incompatible with the current version of Sugar.

[tonyforster]

In the spirit of empowering the user, rather than rejecting bundles requiring a newer version, warn the user that the bundle is likely to have problems but allow them to proceed if they want.

[wadeb]

In the case I'm thinking of, the new ToolBar classes, activities which have been written to the new API simply fail to start. Without this feature, the user will simply experience the infinite blinking activity icon.

Most activities do gracefully support various Sugar versions, this is just for the extreme case where it won't work at all.

(If an enterprising user wants to circumvent it, they can always modify activity.info.)

[garycmartin]

How about host_version? That was always the specified method for this, but I don't think it ever had any code love. Here's a recent feature revival request from Christoph:

 http://wiki.sugarlabs.org/go/Features/Host_Version

To be honest the revived software updater (by David) and its use of activities.sl.org, and also that activities.sl.org pickup up on Sugar versions if you use Browse to download something new, should stop this issue in most cases other than distros packaging up the wrong thing without testing, in error. But I'll be willing to help support a 'belt and braces' approach such as an extra 'don't run this' .info entry – though I consider it a 'fail' if a user has to get this far (i.e. can we try and put the effort into get the pulsing icon startup process smart enough to know when an activity fails, perhaps even some UI friendly pointer to the logs and/or reporting, then we solve this for all Activity fail cases).

[garycmartin]

Replying to wadeb:

In the case I'm thinking of, the new ToolBar classes, activities which have been written to the new API simply fail to start. Without this feature, the user will simply experience the infinite blinking activity icon.

Please file a bug ticket against the activity (if its not part of Sucrose), it's trivial to fix in most cases (see Calculate in GIT, and it had extensive toolbars that needed dual paths). Can I ask how you managed to install a wrong version given that activities.sl.org directs you to download the version for your release of Sugar? Perhaps there's a bug there that needs fixing?

[wadeb]

It was my own fault - I was using SoaS Strawberry, and wanted to do some work on Terminal. I cloned the latest from Gitorious and was surprised when it failed so strikingly.

That said, the ASLO and Updater protections are great! I'm still a bit worried about other "non-centralized" use cases like sharing .xo files via email or USB key. And for hackers like me, it would at least be helpful to see a real error message.

[wadeb]

Replying to garycmartin:

How about host_version? That was always the specified method for this, but I don't think it ever had any code love. Here's a recent feature revival request from Christoph:

 http://wiki.sugarlabs.org/go/Features/Host_Version

I wasn't aware of the host_version field, thanks for pointing it out! It would be easy enough to use that instead. My only concern is that older versions of Sugar did not define a host version AFAIK.

And it will be one more number to keep track of when doing releases. Say 0.86.1 accidentally introduces an incompatibility, activity authors would be unable to declare it. So using the actual version number seems more straightforward to me.

Regarding the pulsing startup icon, I agree that it needs to be fixed. I looked a bit at the startup code but haven't figured out how to do it yet.

[sascha_silbe]

Related patch:  Check for required activity deps before installing