57 lines
1.9 KiB
Markdown
57 lines
1.9 KiB
Markdown
|
# 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/
|