#4906 NORM Never A: Downloading a higher version of an activity doesn't upgrade the one in the XO

[Zarro Boogs per Child]

#4906: Downloading a higher version of an activity doesn't upgrade the one in the
XO
--------------------+-------------------------------------------------------
 Reporter:  gnu     |       Owner:  marco         
     Type:  defect  |      Status:  new           
 Priority:  normal  |   Milestone:  Never Assigned
Component:  sugar   |     Version:  Build 623     
 Keywords:          |    Verified:  0             
--------------------+-------------------------------------------------------
 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?

-- 
Ticket URL: <http://dev.laptop.org/ticket/4906>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system