The story so far: The Develop activity uses the bundle format natively. Thus, it relies on bundlebuilder.py to create bundles and activitybundle.py to install them. But many activities have developed their own way of creating bundles, and do not follow the bundle spec (missing or incorrect MANIFEST). This means that their bundles do not rebuild correctly in Develop, which could lead to data loss in the current incarnation. So, I have to fix bundlebuilder to have more error checking, and activitybundle to throw warnings to encourage people to follow the spec. Also, there is a major part of the sugar spec unimplemented - the part where people can install activities by joining a shared instance of them. Implementing this will, almost inevitably, mean changes in the bundle spec. If I am going to start enforcing the spec, it would seem like the logical time to update the spec to work for updates. Some terminology, and an idea from the mini-conference: By "a bundle" I mean a specific set of bytes. Any change in those bytes means it's a different bundle. Yet actually there are some changes I generally don't care about. Using a different zip algorithm on the same set of files, for instance. Another *possible* instance is a change in translation strings/ localizable icons that does not touch any executable code. I have a proposal (see below) in which such "extras" would be exempt from signature. Thus, when precision is important, I will use "executable bundle" to denote everything with the same valid main signature - that is, everything which has identical executable code. At the mini-conference, a shortcut to key management was proposed, where a developer would create a special-purpose key when they started a new activity, and sign all versions of that activity with their key. This is called the "activity's key" and the signature using this key is the "main signature". This idea assumes that key management is manual - either they send the key itself to collaborating developers, or they accept and apply patches and sign the results locally. If we decide that there are important key management issues missing from this picture, we could do something like SPKI. Thus the original developer would become an authority, and they would grant signing rights to other keys. Even in this case, "main signature" will refer to whatever set of data constitutes a valid signature under this scheme. Generally speaking, such data should not require network confirmation, although a finite lifetime is acceptable. All bundles signed with the same activity's key are known as an "unbroken activity thread". It is assumed that key management would work and that there would be no forking within an activity thread (aside from, possibly, temporary experimental branches which never move beyond one machine). I propose that the unbroken activity thread should be the basic unit of analysis in sugar, and that each such thread should have a unique "bundle ID" (like org.laptop.392A7F). If the key is lost or somebody wants to create a new version (and risk forking), there could be different bundle ID's that are ancestor and descendant (and handle the same files). These are part of the same "[broken] activity thread", which inevitably means that forks are possible. In my proposal, broken activity threads can be identified using the alleged history from the later version, which consists of prior bundle IDs and last-common-versions. Also relevant to this discussion is the new planned journal design at <a href="http://wiki.laptop.org/go/Designs/Journal">http://wiki.laptop.org/go/Designs/Journal</a>. Note that there are two kinds of things in the journal: "actions", which, as m_stone puts it, are "like UI completions", and "objects", which are more like normal files (pictures, documents, etc.) with mime types. Actions contain objects, but those objects are also accessible independently. See also <a href="http://wiki.laptop.org/go/Designs/Activity_Management">http://wiki.laptop.org/go/Designs/Activity_Management</a>. "Favorite" bundles are visible in the "Home screen" (or "donut"), while all activities are available in the "activity list [view]". The issues The point of all of this is the user experience that it enables. Some possible goals (including straw men): 1"no such thing as versions": all actions are associated with a given executable bundle, and can only be opened with that bundle. The favorites can be any set of bundles, whether or not these have an ancestry relationship. The XO does not garbage collect (GC) old bundles until there are no more instances which use them. 1a"NSTAV ++": there is some way to manually open an action with a different bundle. What is the UI to make this easier? 2"latest version, but no such thing as forks": All actions are 100% upward-compatible across unbroken activity threads (when they aren't, you just break the thread). All actions open with latest version in an unbroken thread and "favorite" is an attribute of an unbroken thread - the latest version available is the one that opens. Broken activity threads are treated as in NSTAV. 2a"NSTAF ++": as above, but broken activity threads are treated as in NSTAV ++ 3"no such thing as security": As NSTAF, but auto-updates cross breaks in activity threads. If you have both sides of a fork, whichever one you got second shows up as a separate activity. (->)"xxx with friendly reminders for xxx": when you get a new version of an activity, there is some UI reminder (badges in the favorite view and on actions?) to update your favorite and your actions to the new version. Possibilities: NSTAV wfrf NSTAF, NSTAV wfrf NSTAS, NSTAF wfrf NSTAS. (cute extra possibility: when you update your favorite activity to a new version, the UI asks you "why did you do that?". If you give an answer, this answer is visible in your shared instances of that activity to those with lower versions. This is safer than advertising new versions with changelogs from the author, since this way by nature they come from friends/ known sources. Dubbed "user-generated changelogs" on IRC, which moniker prompted "<cjb> homunq: OH MY GOD STOP") "xxx with offloading garbage collection": NSTAV can easily lead to many actions on the same machine which refer to different bundles from the same thread. If disk space is short, it is possible to aggressively upload these to the school server, and download them as needed. This can lead to actions which do not work until you have connectivity. Note, however, that these actions would still be *visible* in the journal and that their object contents (the actual files) would still be accessible from there. Since we've all lived with just objects, no actions, until now (ca. 1987 MacOS "Switcher", and other "save workspace" gizmos, aside), I think this is acceptable. (*>)"Serious magic": keep usage statistics of all bundles on the school server, including who manually chooses which bundle version and what their choices were. If these statistics show a clear and stable preference for version Y over version X, tell all local XOs to make Y a default over X. also possible: (*l>)"Serious local magic", where switching from X to Y is auto-defaulted the Nth time you do it manually on a given machine.) "Serious magic" is essentially interchangable with "with friendly reminders for" - thus possibilities such as NSTAF slm NSTAS, or NSTAV sm NSTAF. My vote I would vote for NSTAF wfrf NSTAS - that is, the most agressive non-strawman option about auto-updates. This allows for a decent level of garbage collection. One weakness that I do see with this option is its relatively strong assumption that later versions are better; I am open to proposals on how to weaken this assumption, though I do think it is good in 90% of the cases. My proposal Before I got pushback on this, I had made some proposals about implementation which essentially assumed something like NSTAF wfrf NSTAS. These proposals are available at  <a href="http://wiki.laptop.org/go/Talk:Activity_bundles#Proposals_for_update">http://wiki.laptop.org/go/Talk:Activity_bundles#Proposals_for_update</a> . My timeline I have enough little bug fixes pending to occupy me for this week. I would like to have some kind of game plan starting next week. That could be just "this is too hard to decide now, just start enforcing the activity bundle format as it stands" but I would prefer to have a clear bundle format, or at least an agreement on the UI goals it should support, by that time. Jameson ps. If you don't like the acronyms, feel free to use the numbers/symbols. NSTAV slm NSTAS == 1*l>3