Software updater
The 8.2 releases contain a new "software update" control panel, used to update activities installed on an XO. (In release 9.1 it is expected that the control panel will be able to update the core OS as well, but at the moment olpc-update is still used for that task.)
There are two main features of the software update system. First, activity authors can specify an "update url" at which new versions of their activity can be found. If no update url is specified, the system falls back to the Activities page on the OLPC wiki, allowing a convenient bootstrap for existing activities with no specified "update url". Second, the software updater contains an "activity group" feature which makes it easy to install and maintain a set of activities on an XO. Machines in the Give One Get One program are expected to be shipped subscribed to the Activities/G1G1 group; machines shipped to Peru have shipped with the activities listed on the Activities/Peru group page; and our "joyride" builds for developer testing are subscribed to the Activities/Joyride group by default.
For activity authors
Using the activity update mechanism is intended to be as simple as possible. If you like, you need make no updates to your activity at all; just keep the Activities page updated with the most recent version of your activity. If your activity is included in the G1G1, Joyride or Peru groups, keep those pages updated as well. (An planned improvement to our template system will eventually keep these pages automatically in sync, but for the moment you should check each page for consistency.)
After 8.2 is released and we start working on the next build, we will freeze the set of activities known to work well on 8.2 at Activities/8.2. If you then released a new version of your activity which is backwards compatible with 8.2, you should update the Activities/8.2 page as well. (Again, our new templates will eventually do this automatically.)
The main advantage of this system is its simplicity: anyone can upload an activity bundle to our wiki and update the activities information there; no special web hosting ability is required. This is, however, also its main disadvantage: *anyone* can update an activity bundle there. If you want a little more control over who can release new versions of your activity, you can specify an update_url in the activity.info file in your activity. By pointing the update_url at a web site you control, you can ensure that only you can publish new versions of your activity.
Consult the documentation on the activity bundles page for more information about the update_url field, and the activity microformat page for descriptions and an example of the information which should be present at the page pointed to by update_url. The format has been designed to be easily embeddable into an existing web page or blog for your activity.
Activity groups
You can edit the set of activity groups you are subscribed to using the software update control panel. The same activity microformat is used for specifying activity groups. It is hoped that it will be easy for motivated individuals to create and share their own activity groups.
Lists of subscribed activity groups are kept in a simple one-line-per-url file format. The update control panel first looks for a group list in ~olpc/Activities/.groups (which will be preserved across upgrades, since it is in the user's home directory). If this file is not present, the group list in /etc/olpc-update/activity-groups is used. This allows the joyride builds, for example, to default to the Activities/Joyride activity group.
If the /etc/olpc-update/activity-groups file does not exist, the system performs a special test to determine if we are upgrading from an old release where activities were installed as part of the core OS, by looking to see if an activity with bundle_id 'org.laptop.WebActivity' is installed. If it is not, it guesses that the user would be left with the "no activities" bug after this upgrade (<trac>7093</trac>), and adds the G1G1 group to work around this.
The group URL uses the same "url extension" mechanism documented for the update_url field on the activity bundles page. That is, if the group URL is http://wiki.laptop.org/go/Activities/G1G1, the updater (running on "build 758" of an 8.2.1 release) will look at the following URLs in order:
- http://wiki.laptop.org/go/Activities/G1G1/758
- http://wiki.laptop.org/go/Activities/G1G1/8.2.1
- http://wiki.laptop.org/go/Activities/G1G1/8.2
- http://wiki.laptop.org/go/Activities/G1G1
This allows you to provide different versions of the activity group if some of your activities are not compatible with older (or newer) releases. Generally it is expected that the unsuffixed version of the group URL will always contain the latest versions of the activities for the very latest release, and that page will be "frozen" at an appropriately suffixed page as releases happen and work begins on the next release.