Release Process/Planning
Choose a version number
Use the naming rules described at Release Process to pick a version number for the release.
Create a release page
Create a page on this wiki, named according to the chosen version number, e.g. 11.2.0
Make sure this page is in the releases category, and start filling in the semantic tags to the extent possible (look at previous releases for examples). At the very least, complete the status property with value "planning".
Create a release plan
You should now construct a release plan, publishing it on this wiki. It can either be published on the release page you created above, or as a sub-page, with an obvious link on the release page.
The plan that you create will vary depending on the motivation for the release, if it is a major or minor release, etc. It is normally a mix of pulling feedback from deployments and the community and including recent developments from inside and outside the OLPC community.
The release plan should define the schedule, dividing the time into stages (milestones) of development and stabilization. The usual model is:
- Development stage - this is the only time when new features can land
- Bug fixes only - no new features are accepted, but problems can be fixed
- Regression fixes only - the only changes accepted are regression fixes, i.e. bugs that exist in this release that did not exist in previous releases.
The release plan should define the release date (which will naturally occur at the end of the final milestone).
If appropriate, the release plan should discuss a set of features to be included in the release (the exact selection will normally be dictated by the timing of the schedule, but it doesn't hurt to plan what you will work on).
Schedules for major releases should be carefully considered against the Sugar release schedule. Significantly, the "bug fix" stage, where activities are usually frozen, should start at a point where all translations for a given Sugar release (and its activities, as those translations tend to follow at the same time) have been committed. Otherwise the freeze is likely to be 'polluted' with translation update requests, which can possibly regress in themselves or even cause activity failures, and might otherwise be intermixed with newer code changes.
The release plan should identify a release manager - someone to oversee the process, produce and publish builds, coordinate development according to the schedule, etc.
As details solidify on this plan, update the main release page with the semantic tags (e.g. release date) as appropriate.
Announce
When the plan is somewhat complete, it should be announced to the public, at the very least on the devel mailing list. This allows peer review and informs our customers at the very earliest opportunity of our plans.
In some cases, the release might have been announced even before planning started, as a means of soliciting feedback from customers which would be used to shape the release plan.
