Opened 14 years ago

Last modified 10 years ago

#1442 accepted enhancement

Reject activity bundles which require a newer version of Sugar

Reported by: wadeb Owned by: wadeb
Priority: Normal Milestone: Unspecified
Component: Sugar Version: Unspecified
Severity: Unspecified Keywords: dev-love
Cc: sascha_silbe, km0r3, smparrish Distribution/OS: Unspecified
Bug Status: New

Description

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.

Attachments (2)

Change History (17)

comment:1 Changed 14 years ago by 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.

comment:2 follow-up: Changed 14 years ago by 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.)

comment:3 follow-up: Changed 14 years ago by 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).

comment:4 in reply to: ↑ 2 Changed 14 years ago by 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?

comment:5 Changed 14 years ago by 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.

comment:6 in reply to: ↑ 3 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by sascha_silbe

  • Cc sascha_silbe added

comment:8 Changed 14 years ago by wadeb

  • Owner changed from tomeu to wadeb
  • Status changed from new to accepted

comment:9 Changed 14 years ago by bernie

  • Keywords dev-love added

comment:10 Changed 14 years ago by bernie

  • Cc km0r3 added

comment:11 Changed 13 years ago by smparrish

  • Cc smparrish added

comment:12 Changed 13 years ago by smparrish

  • seeta_dev set to Shanjit, Kandarp

comment:14 Changed 11 years ago by dnarvaez

  • Bug Status changed from Unconfirmed to New
  • Priority changed from Unspecified by Maintainer to High

comment:15 Changed 10 years ago by godiard

  • Priority changed from High to Normal
Note: See TracTickets for help on using tickets.