View source for XS Roadmap

{{OLPC}}

= Release goals =

'''The next release is 0.3'''

== v1.0 ==

* Features from 0.9
* Bugfixes
* Upgrade path from any earlier 0.x release

== v0.9 aka ''Wishlist''==

Wishlist for the 0.x series.

* '''[[XS_Manageability]]''' - solid, secure and flexible remote management for XS, inspired in ISConf and PlanetLab
* '''[[XS_HTTP_Proxy]]''' a strong double-proxy setup inspired on CoDeeN
* '''[[XS_Backup]]''' solid, flexible scheme to backup and restore the XS itself
* '''[[XS_AdminUI]]''' simple admin UI to support some key usage scenarios
* Port to Fedora 9
* Webapps
** '''[[XS_Mediawiki]]''' - with customised UI, options to load/update prepackaged Wikipedia content, local content, SSO
* '''[[XS_Library]]''' - Content repository infrastructure

== v0.4 ==

* '''[[XS_Moodle]]''' - with customised UI, options to load prepackaged course content
* XO-XS automagic authentication


=== Peru XO Upgrade Request ===
Requirement: The XO should be able to get the latest build from the school
server

* The administrator makes the desired build available in the designated
directory. When ready, the administrator requests to 'push' the build to all
laptops as they come on line. Both of these activities should be an
easy-to-use UI at the school server.

* A test requirement is the ability to create a white list of serial numbers
that should be upgraded with the push.

=== Peru XS Database Request ===

Requirement: Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs:

* Version of code
* Which laptops are being seen each day
* Total number of laptops being seen per day
* Number of laptops accessing the internet
* List of URLs being accessed
* List of URLs per laptop
* Which activities are being used per laptop

== v0.3 ==

Matches XO's "8.1.x" releases. Will be deployed in Peru - our first large-scale install of XSs, many of them with nil or spotty connectivity, so strong focus on manageability.

* DS-Backup as per [[XS_Blueprints:Datastore_Simple_Backup_and_Restore]]
* Root password management as per [[XS_Blueprints:OTP_root_passwords]]

* Manageability

= Release schedule =

The XS should see a new ''feature'' release every ~4 weeks until we hit v1.0. At that point we will encourage installations to switch to v1.0 and ensure the upgrades from earlier releases to 1.0 work smoothly. From 1.0 onwards the release cycle will be slower - probably about 4 months.

In calendar terms, we are very loosely talking about 

= Versioning Scheme =

Releases will follow a '''<major>.<feature>.<minor>''' versioning scheme, as follows: 

* 2.0 is our long-term "Next Gen" release somewhere in the distance
* 1.0 is our mid-term "we are proud of it - features and stability" release
* 0.3 will be the first release managed by Martin Langhoff, to sync with Peru's April 2008 deployment
* 0.2 is Build 163/164 by Wad.

If for example 0.2 needs bugfixes, we'll see a 0.2.1 release. The 0.9 to 1.0 transition will be about stability and polish.

Exactly what happens between 0.2 and 1.0 will be defined via release goals and blueprints (similar to Ubuntu's approach) which will be managed in dev.laptop.org .

'''Note''': On dev.laptop.org our release names are prefixed with "xs-" so 1.0 is xs-1.0.

== Upgradeability Considerations ==

A key consideration is that once XS is widely installed, countries/regions will want to limit the number of upgrades they apply to the XS. During the 1.x cycle, we must support environments where the XS has a yearly upgrade. That means that with a 4-month cycle 1.0 must be able to upgrade to 1.4 smoothly.

Deployment managers need to be aware that XS with versions earlier than 1.0 can be managed in two ways:

* Once 1.0 is ready, there will be a special upgrade procedure to get from 0.x to 1.0 with minimal steps.
* Upgrading through each version.

Installations using 1.x will be expected to upgrade at least yearly.

= Key metrics =

When judging release goals, there are some key metrics we ''must'' consider (and are not always obvious):

* A common scenario will be an unattended, unmanaged XS that only gets powered up and forgotten. Might have Internet/WAN access, but probably not. Are we improving/regressing the XS performance for that scenario?
* How about the minimal configuration scenarios?

''Note:'' Old releases go to the [[XS_Changelog]]


[[category:SchoolServer]]