XS Roadmap: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 25: Line 25:


Deployment managers need to be aware that XSs must be upgraded frequently until 1.0, and yearly during the 1.x cycle.
Deployment managers need to be aware that XSs must be upgraded frequently until 1.0, and yearly during the 1.x cycle.

= 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?


= Release goals =
= Release goals =
Line 34: Line 41:
* upgrade path from any earlier 0.x release
* upgrade path from any earlier 0.x release


== 0.? ==

Install web based activities (Moodle, Mediawiki) with identity mgmt (SSO) and Sugarised UIs. Initial [[XS DevKit]] toolset with tools to prepare the install image with additional content & software, like a slice of Wikipedia content, Moodle demo courses, etc.


== 0.2 ==
== 0.2 ==

Revision as of 15:46, 21 March 2008

  This page is monitored by the OLPC team.

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 160 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.

Release schedule

The XS should see a new feature release every 3~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.

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 XSs must be upgraded frequently until 1.0, and yearly during the 1.x cycle.

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?

Release goals

1.0

  • features from 0.9
  • bufixes
  • upgrade path from any earlier 0.x release

0.?

Install web based activities (Moodle, Mediawiki) with identity mgmt (SSO) and Sugarised UIs. Initial XS DevKit toolset with tools to prepare the install image with additional content & software, like a slice of Wikipedia content, Moodle demo courses, etc.

0.2

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

  • Backups
  • Install config
  • Security scheme
  • Manageability


Note: Old releases go to the XS_Changelog