#1053 closed defect (fixed)
bundle gets installed each time it is started from Journal
Reported by: | sascha_silbe | Owned by: | tomeu |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | |
Component: | Sugar | Version: | Git as of bugdate |
Severity: | Minor | Keywords: | r+ |
Cc: | Distribution/OS: | Unspecified | |
Bug Status: | New |
Description
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.
Attachments (1)
Change History (4)
Changed 14 years ago by sascha_silbe
comment:1 Changed 14 years ago by 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.
comment:2 Changed 14 years ago by tomeu
- Keywords r+ added; r? removed
- Resolution set to fixed
- Status changed from new to closed
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.
install bundle only if versions differ