From c337025e3aead69f5e9d1bbbbb88bf2ab0128a39 Mon Sep 17 00:00:00 2001 From: David Brown Date: Tue, 12 Sep 2017 10:36:19 -0600 Subject: [PATCH] Document the release process An initial document describing the mechanics of how a release is made. This is a start of documenting our full development process. Signed-off-by: David Brown --- docs/index.md | 1 + docs/release.md | 56 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 docs/release.md diff --git a/docs/index.md b/docs/index.md index e31b4150..ca08c728 100644 --- a/docs/index.md +++ b/docs/index.md @@ -25,6 +25,7 @@ target with a complete port planned. - Testing - The [Zephyr]({% link testplan-zephyr.md %}) test plan. - The [mynewt]({% link testplan-mynewt.md %}) test plan. +- Our [release process]({% link release.md %}). There is also a document about [signed images]({% link signed_images.md %}) that is out of date. You should use `imgtool.py` diff --git a/docs/release.md b/docs/release.md new file mode 100644 index 00000000..7a35b896 --- /dev/null +++ b/docs/release.md @@ -0,0 +1,56 @@ +# Release Process + +The following documents the release process used with mcuboot. + +## Version numbering + +MCUboot uses [semantic versioning][semver], where version numbers +follow a MAJOR.MINOR.PATCH format with the following guidelines on +incremeting the numbers: + +1. MAJOR version when you make incompatible API changes, +2. MINOR version when you add functionality in a backwards-compatible + manner, and +3. PATCH version when you make backwards-compatible bug fixes. + +We add pre-release tags of the format MAJOR.MINOR.PATCH-rc1. + +## Release Candidates + +Prior to each release, tags are made (see below) for at least one +release candidate (a.b.c-rc1, followed by a.b.c-rc2, etc, followed by +the official a.b.c release). The intent is to freeze the code for a +time, and allow testing to happen. + +During the time between rc1 and the final release, the only changes +that should be merged into master are those to fix bugs found in the +rc. + +## Tagging and Release + +To make a release, make sure your local repo is on the tip version by +fetching from origin. Typically, the releaser should create a branch +named after the particular release. + +Create a commit on top of the branch that modifies the version number +in the top-level `README.md`, and create a commit, with just this +change, with a commit text similar to “Bump to version +a.b.c”. Having the version bump helps to make the releases +easier to find, as each release has a commit associated with it, and +not just a tag pointing to another commit. + +Once this is done, the release should create a signed tag: +``` bash +git tag -s va.b.c-rcn +``` +with the appropriate tag name. The releaser will need to make sure +that git is configured to use the proper signing key, and that the +public key is signed by enough parties to be trusted. + +At this point, the tag can be pushed to github to make the actual +release happen: +``` bash +git push origin va.b.c-rcn +``` + +[semver]: http://semver.org/