Let me try to sketch out the plan understand and interpret it from <a href="http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1">http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1</a>. (episode 2 was more about how to handle the files/bundles or objects/actions distinction, which is farther off).<br>
<br>1. in the future, object ID will just be a hash of the non-human-readable signing key for an activity.<br><br>1.a) this will not change over minor version changes. It may not change over major version changes, or, if author intends bugfix releases of the old version, it may deliberately change. If there is a discontinuity in authorship (key lost) it must change.<br>
<br>
1.a)1)when we have signatures, hash collisions will be assumed to be a deliberate attack, and will just refuse to install.<br>b) for right now, we can just use object ID.<br><br>2. Within each object ID, there can be any number of versions simultaneously installed.<br>
<br>2.a) just id/version is not unique, for instance if an activity is under active development on that machine.<br><br>2.a)i) An idea of mine, not discussed yet: we actually could try to enforce the idea that any two activities which match on {id,version,bool(has valid signature)} are interchangeable - just silently use the first one seen for bundles with a valid signature (release versions), and the last one seen for b. without v.s. (development versions.<br>
<br>2.b)Even if we can get some combination of data (besides just hashing the whole bundle) that is unique, or if we make a pre-signature approximation that id/version is unique, there will still be a large potential for clutter.<br>
<br>3. Which one to use?<br><br>3a) Each journal object will have metadata with all identifying data (id, version, sig?, hash) of the last activity.<br><br>3b) For some activity ids, there will be (at most) one starred version.<br>
<br>3c) Journal objects will open by default with {own id, max(starred version, own version)}, or if that is unavailable starred version, or if that is unavailable latest version.<br><br>3d) Unstarred id's can still be grouped/collapsed in the activity list.<br>
<br>3d) imported objects will open by default with starred or latest version<br><br>4. Garbage collection of old installed versions (this patch)<br><br>4a) Any versions older than starred version are eligible for GC.<br><br>
4b) Suggestion (not discussed): Grace period to notice broken features: When starred version changes, garbage collection on that ID is frozen until the new starred version has been used at least 3 times. <br><br>4c) Suggestion: Suggested updates: First time quitting a version newer than starred version, ask user if they want to move the star. <br>
<br>4d) Suggestion: when you see a shared activity in the mesh, some UI hint to show if it is newer/older/same version as your starred/latest version. (also, see "imposing changelogs" in the discussion)<br><br>...<br>
<br>As an aside, I think that it is a mistake to impose integer versions. I think that a general n-number versioning system, with a hyphen as a separator (to avoid the 1.10 problem), but Glucose only understands the ordering and makes no distinction between major and minor version. This would support integers, major-minor, major-minor-bugfix, or other similar systems, without imposing one.<br>
<br>Jameson<br>