On Wed, Jul 09, 2008 at 02:29:17PM -0400, Kim Quirk wrote: > With almost 400,000 deployed in the world, we need to have some good > discussions on the backward compatibilty and upgradability of Activities. > > Some of the bugs Charlie is writing up from the QA first look at joyride may > be answered by upgrading an activity to a newer one. > > So here are the questions we need to discuss: > > 1 - Is there anyway to ensure backward compatibility of activities (the > 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. > > 2 - For support purposes, do we need or want to say that activities will be > backward compatible only across the year designator (8.1 activities will > work with 8.2; but from 8.x to 9.x, the activities will need to be updated > and probably retested and checked for new translations). >
> 3 - Since I think it is going to be really hard to do either 1 or 2 above, > then we have to have a strategy for easy activity upgrades. We've talked > about this for a long time... do we have a proposal that we can really > implement as part of the 8.2 release? Problem: We release a new activity that works on our development stream, but how does a user know if it is supported on their system? How do they know to download it? What if it has system dependencies which are unmet on the user's existing system? Commonly utilized solution (at least in the Linux world): Use a package manager to manage such details for the user. For each packaged version of an activity, record which versions of other system libraries and applications it requires and where to download it. When the user attempts to install a package, check that its dependencies are met in the existing system. If they are not, ask the user if they wish to make the required upgrades and inform them of the consequences (in terms of memory usage and other software breakage). Such a system could also be used to deliver security updates and manage incremental system upgrades. (For all discussion of security I've seen on the devel list, the distribution of security-related software updates is not something I have noticed. How are we planning on doing this outside of olpc-update?) The problem of software deployment which you note in #3 is _exactly_ the kind of problem that package management system could be used to solve. We already ship one on the laptop (yum)! Perhaps we could be using it to handle our activity updates? If the problem is that yum is slow and awful, then maybe we need to start thinking about using apt. In the long run I have trouble imagining how this problem will be solved without roughly approximating the behavior of apt or rpm package management systems. I suggest we start exploring methods to install and upgrade activities using such systems. I do not know if this is something we can manage for the 8.2 release, but I would be more than willing to start working on it as soon as necessary. Erik _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
