Release Process/Release: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
At the end of the [[Release Process/Stabilization|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.
At the end of the [[Release Process/Stabilization|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 ==
== Update download.laptop.org ==


For each laptop model, the build should be moved from 'candidate' to 'official' in the files hierarchy, with a symlink put in place from the candidate directory to avoid breaking old links. The 'latest' symlink under official should be updated.
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 http://download.laptop.org index.html front page should be updated (manually)
The release notes should be published under the [[Release notes]] page, e.g. [[Release notes/8.2.0]].


== Update download.laptop.org ==
== Finalize release notes ==


At this point, the release notes should be checked and published as final with any <nowiki>{{draft}}</nowiki> tag removed.
The http://download.laptop.org index.html front page should be updated (manually) and the build moved from 'candidate' to 'official' in the files hierarchy.

== Finalize frozen repositories ==

The [[Frozen repositories]] used in the release should now be finalized (see [[Frozen_repositories#Finalizing_a_release]]).


== Make build system release ==
== Make build system release ==
Line 18: Line 22:
# After committing, a git tag (with that version number) should be made and pushed
# After committing, a git tag (with that version number) should be made and pushed
# A new tarball should be released
# A new tarball should be released
# The [[OS Builder]] page should be updated with a link to that tarball
# The new version should be packaged in Fedora
# The new version should be packaged in Fedora


Line 38: Line 41:


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

== Update updates.laptop.org ==

Verify each released build is listed as an rsync module:

rsync rsync://updates.laptop.org/

If the builds are missing, probe the updates server using the build directory name, so that it will fetch the build and populate the filesystem. For example:

rsync rsync://updates.laptop.org/build-13.2.4_xo1.5-16

This takes about 3.3 minutes. Then repeat the verify step.

== Update signed firmware ==

If firmware version has changed since prior release, update the table of signed firmware files in [[Upgrading firmware]].

== Add version to trac ==

Add the version and release date to the trac list of versions for reporting tickets.

== Close milestone on trac ==

Close the milestone for the release.

== Update Wiki Latest Releases ==

Update [[Template:Latest_Releases/stable]] in case there's anybody still using the Wiki.

Latest revision as of 21:13, 21 December 2017

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.

Update download.laptop.org

For each laptop model, the build should be moved from 'candidate' to 'official' in the files hierarchy, with a symlink put in place from the candidate directory to avoid breaking old links. The 'latest' symlink under official should be updated.

The http://download.laptop.org index.html front page should be updated (manually)

Finalize release notes

At this point, the release notes should be checked and published as final with any {{draft}} tag removed.

Finalize frozen repositories

The Frozen repositories used in the release should now be finalized (see Frozen_repositories#Finalizing_a_release).

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 new version should be packaged in Fedora

Update release page

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

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.

Update updates.laptop.org

Verify each released build is listed as an rsync module:

rsync rsync://updates.laptop.org/

If the builds are missing, probe the updates server using the build directory name, so that it will fetch the build and populate the filesystem. For example:

rsync rsync://updates.laptop.org/build-13.2.4_xo1.5-16

This takes about 3.3 minutes. Then repeat the verify step.

Update signed firmware

If firmware version has changed since prior release, update the table of signed firmware files in Upgrading firmware.

Add version to trac

Add the version and release date to the trac list of versions for reporting tickets.

Close milestone on trac

Close the milestone for the release.

Update Wiki Latest Releases

Update Template:Latest_Releases/stable in case there's anybody still using the Wiki.