Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This page documents the Release manager responsibilities so that it serves as a knowledge repository for Release managers.
The description of the different Milestones leading to a release can be found in the following Program Management sections:
Each release has a GitHub issue associated with it that contains the full checklist. After a release is complete, a checklist for the next release is created. This is the checklist for v1.11.0.
Note: This section uses tagging 1.11.0-rc1 as an example, replace with the appropriate version.
Every time a release candidate (or the final release) needs to be tagged, the following steps need to be followed:
- Update the
VERSIONfile in the root of the Git repository. If it's a release candidate, use
EXTRAVERSION = rc1
Commit the update to the
release:as a commit tag.
Check that CI has completed successfully before tagging.
Tag and push the version, using annotated tags:
- If it's a release candidate:
$ git tag -a v1.11.0-rc1 <Use "Zephyr 1.11.0-rc1" as the tag annotation> $ git push firstname.lastname@example.org:zephyrproject-rtos/zephyr.git v1.11.0-rc1
- If it's a release:
$ git tag -a v1.11.0 <Use "Zephyr 1.11.0" as the tag annotation> $ git push email@example.com:zephyrproject-rtos/zephyr.git v1.11.0 $ git tag -a zephyr-v1.11.0 <Use "Zephyr 1.11.0" as the tag annotation> $ git push firstname.lastname@example.org:zephyrproject-rtos/zephyr.git zephyr-v1.11.0
- If it's a release candidate, create a shortlog of changes between the previous release:
$ git shortlog v1.10.0..v.1.11.0-rc1
- Find the new tag at the top of the releases page, edit the release with the "Edit" button and then do the following:
If it's a release candidate:
- Name it
- Copy the shortlog into the release notes textbox (don't forget to quote it properly so it shows as unformatted text in Markdown)
- Check the "This is a pre-release" checkbox
- Name it
If it's a release:
- Name it
- Copy the full content of
docs/release-notes-1.11.rstinto the the release notes textbox
- Copy the full list of GitHub issues closed with this release into the release notes textbox (see below on how to generate this list)
- Name it
- Send an email to the mailing lists (zephyr-announce and zephyr-devel) with a link to the release
Listing all closed GitHub issues
The release notes for a final release contain the list of GitHub issues that have been closed during the development process of that release.
In order to obtain the list of issues closed during the release development cycle you can do the following:
- Look for the last release before the current one and find the day it was tagged:
$ git show zephyr-v1.10.0 tag zephyr-v1.10.0 Tagger: Kumar Gala <email@example.com> Date: Fri Dec 8 14:26:35 2017 -0600
- Find a way to list all the issues that have been closed between that date and the day of the release. In the case of 1.11.0, this was: 2018-03-09 - 2017-12-08 = 91 days. A simple Smart Query on Ship yields the full list of issues closed during the last 91 days. We do this instead of using the Milestone because sometimes issues are opened and closed without a Milestone being set. This is equivalent to using this GitHub search query.