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 <david.brown@linaro.org>

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`

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/