Downloading a higher version of an activity doesn't upgrade the one in the XO
|Reported by:||gnu||Owned by:||rwh|
|Keywords:||review+||Cc:||jg, kimquirk, marco, tomeu, AlexL, mstone|
|Deployments affected:||Action Needed:|
I had a SimCity activity with activity_version = 1 installed. I downloaded a new one with activity_version = 2. It was not installed; instead, when I resumed it from the journal, the old version 1 copy was resumed.
This seems to be a critical bug for Ship.1; it would mean that buggy activities couldn't get replaced by fixed ones.
There are two cases that may be handled differently. The existing activity could be in /usr/share/activities if it came with the OS. Or the existing activity could be in /home/olpc/Activities if it was previously downloaded. In both cases, the higher-version application should be the one that runs when you resume that .xo file from the journal. (And I think it should replace the icon on the bottom bar, so new invocations will get the new version.)
Whether installing a new version should physically remove the older version (freeing up its scarce flash space) is a separate question. If it doesn't get deleted, how and when WILL it ever get deleted? If it doesn't get deleted, is there any way to access it to run it?
If you use the GUI to remove the new version, does the old version become accessible again?
Change History (26)
comment:1 Changed 8 years ago by jg
- Milestone changed from Never Assigned to Update.1
- Priority changed from normal to blocker
comment:2 Changed 8 years ago by marco
- Cc kimquirk added
- Milestone changed from Update.1 to Retriage, Please!
- Type changed from defect to enhancement