The way I see it, there are TWO kinds of items for which "compatibility" needs to be provided -- executables + data :
* Executables : The problem arises from the "quickness" with which some users (such as I) can switch operating system versions. I sometimes have two different "streams" on my XO (for example, the two "builds" in the /versions directory might be from Update.1 vs. Joyride) -- I can switch in minutes to a different "stream" by just rebooting. Others (including kids) can switch in tens of minutes to a different "stream" by installing a new build from an USB stick. The problem (of providing "compatibility" between Activities and the operating system on which they run) originated when Activities were no longer packaged into the "build". Now, unless the "build" to be fetched is accompanied by a set of Activity EXECUTABLES known to be compatible with that build, any "leftover from previous times" XO Activities might *not* receive the particular version of services from the new-fetched operating system "build" that they expect. The only solution I see is to provide a set of "compatible" Activity versions whenever a "build" version is provided. For kids, that would mean using a facility similar to 'Customization' to put BOTH a "build" and its "Activities" on the same USB stick. [I used the word 'similar' because the kid ought to have the options of either doing a "completely clean" install, or else installing the new build+Activities __without__ wiping out the existing /home/olpc content. (The question of providing "backward compatibility" between leftover /home/olpc data and changed Activity executables is left to another discussion.)] * Data : The problem is that Activities compiled in July might not work correctly with DATA placed into the datastore in February (by the version of the Activity that was installed at that time). The only solution I see is to *insist* that each new version of the Activity __verify__ that it can work with the data (e.g., formats) that are made available to it. If not, the Activity should notify the user of the incompatibility. mikus -------- p.s. One of my "hot buttons" is 'hooking up' additional Activities which are resident on a removable storage device. Obviously, such Activities might be at the wrong version level. Therefore I am interested in there being a "checker" at activity-launch time, which would compare the current operating-system level against the level expected by the activity to be launched -- and at least warn the user if an incompatibility is found. _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar