In GitHub milestones are specified using ids, as opposed to logical names, in query URLs.

Based on the list from the previous step, create release notes for the new release. This used to be done in wiki pages (e.g. Release/2.2/Notes). Release notes are now in the OpenLayers repository, under the notes directory (e.g. 2.12.md). Even though release notes are in GitHub, a Release/x.y/Notes page including a link to the notes in the GitHub repository should be created (e.g. Release/2.12/Notes).

Release Candidate (RC) CycleLet us say that for the RC in question, Z is the incremental release candidate number (starting with 1)

Compile a Release Announcement. The announcement should be located at Release/x.y/Announce/RCZ and should include one of the following:

If this is the first RC (Z is 1): A link to the Release/x.y/Notes wiki, and a brief summary of its contents.

If this is not the first RC, then: A brief summary of all of the tickets that were fixed in the last RC.This should be a summary of the following trac query (where we let W be the previous RC number, i.e. Z-1):

Update news.txt: both in trunk and in the branch, update the /news.txt file to reflect this release. Note that you must be both tricky and quick here, as you must *predict* the correct revision number for the actual tagging of the release, which you will do in the next step. Essentially, this is current release +2 (one for the check-in of news.txt, one for the tag). It seems absurd, but it is good to make sure that no one else is checking in at the same time as this maneuver assumes a quiet wire.