bundle gets installed each time it is started from Journal

[sascha_silbe]

Each time a bundle (itself) gets started from Journal, it will be installed, even if the same version is already installed.
From the IRC discussion:

20:43 < silbe> tomeu: is it on purpose that we install a bundle each time it is "started" 
               from Journal, even if the same version is already installed?
20:43 < tomeu> silbe: not at all
20:45 < silbe> though as i think about it, maybe it's the lesser evil
20:47 < silbe> the issue i'm thinking about is what happens if a user=activity developer 
               doesn't bump the version every time
20:48 < silbe> but maybe we should try to enforce the version some (other) way, instead of 
               working around it in Journal
20:48 < silbe> i guess collaboration uses the version number as well in some way?
20:49 < tomeu> silbe: it should but doesn't afaik
20:50 < tomeu> silbe: the issue of identity of an activity bundle is a tricky one
20:50 < silbe> tomeu: we could go the git way and use the hash of the contents

The attached patch will stop Sugar from installing the bundle if the version number of the already-installed activity matches the one from the bundle.
Just for information (this patch doesn't change anything about it and it's IMO out of scope for this bug): When resuming existing instances it will use the last installed version. Other options would be:
a) the version the instance was created with
b) the latest available version.

[sascha_silbe]

install bundle only if versions differ

[garycmartin]

Just for information (this patch doesn't change anything about it and it's IMO out of scope for this bug): When resuming >existing instances it will use the last installed version. Other options would be:
a) the version the instance was created with
b) the latest available version.

FWIW, as a developer I quite like the current behaviour. It allows me to have different Activity bundle versions in Journal, install and test with the specific version I want. Choice a) would be a bad IMO as when I upgrade an Activity to the latest shiny version I want to access all those lovely new Activity features if I open up existing work; choice a) also assumes you have a all previous versions of an Activity bundle available to install. Choice b) is OK, but prevents me from working with different versions (say I'm hacking on my own version of Write, but still want to be able to use the older official one.

Actually, having been exposed to the git hash scheme of things, I've fast gone off version numbers :-) I'm not sure how I could use Sugar to safely hack on a new version of any Activity, and not risk get clobbered by an official release with that same sequential version number a little later.

[tomeu]

Well, what we currently have is a big mess. I agree with the original intention of this ticket and will apply the patch.

Going forward, I think that we need to first define all the scenarios related to multiple-version support, distributed hacking on activities, and activity sharing.

Then we can agree on the next steps that will solve those scenarios and execute one by one. This is an area that has lots of hard problems but I don't see why we should block completely because of that.

[dnarvaez]

Milestone 0.86 deleted