Release Process/Release

At the end of the stabilization phases, the final release candidate is agreed as good and becomes the final release. This page outlines the steps needed to wrap-up the release.

Write release notes

Each new release should be accompanied by detailed release notes explaining the improvements and significant bug fixes present in the release, alongside installation/upgrade instructions, download links, and any known issues.

The release notes should be published under the Release notes page, e.g. Release notes/8.2.0.

Make build system release

For olpc-os-builder:

1. The version number should be incremented appropriately
2. The suggested_oob_version field in the build configuration should be set to this version
3. After committing, a git tag (with that version number) should be made and pushed
4. A new tarball should be released
5. The OS Builder page should be updated with a link to that tarball
6. The new version should be packaged in Fedora

Update release page

The release page (e.g. 11.2.0) should then be updated.

• The status property should be set to "released"
• The following properties should be set appropriately: Property:Build number, Property:Build system, Property:Build system version, Property:Build platform, Property:Download URL, Property:Firmware

Announce the release

Send a mail to the devel mailing list announcing the availability of the release.

Send the build to the factory

Quanta (the laptop manufacturer) should be informed of the availability of the new build. They will install it on new laptops where the deployment has not provided a custom software image.

To do this, ask a member of OLPC staff to inform Quanta of the new release by sending a mail to the production mailing list.

Quanta will likely do a week or two of their own QA before the new software build hits production.