+After these required numeric components, release version strings
+may contain tags such as as <em>-rc1</em> or <em>-rc2</em>.
+These 'rc' tags indicate "release candidate" versions of the package.
+Like the major/minor/micro numbers, these tags will be manipulated
+by the automated release process.
+
+The release process includes version number manipulations to the tree
+being released, ensuring that all numbers are incremented (or rolled
+over) at the right time and in the proper locations of the repository.
+One of those manipulations creates a repository tag matching that
+release's version label.
+
+@subsubsection releaseversionsdist Packager Versions
+
+Distributors of patched versions of OpenOCD are encouraged to extend the
+version string with a unique version tag when producing external
+releases, as this helps to identify your particular distribution series.
+Knowing that a release has such patches can be essential to tracking
+down and fixing bugs.
+
+Packager version tags should always be suffixes to the version
+code from the OpenOCD project, signifying modifications to the
+original code base. Each packager release should have a unique
+version.
+
+For example, the following command will add a 'foo' tag to the
+configure.in script of a local copy of the source tree, giving
+a version label like <em>0.3.0-foo</em>:
+
+@code
+tools/release/version.sh version tag add foo
+@endcode
+
+This command will modify the configure.in script in your working copy
+only. After running the @c bootstrap sequence, the tree can be patched
+and used to produce your own derived versions. You might check that
+change into a private branch of your git tree, along with the other
+patches you are providing.
+
+You can also "bump" those tags (so "foo1" becomes "foo2" etc)
+each time a derived package is released, incrementing the tag's
+version to facilitate tracking the changes you have distributed.
+
+@code
+tools/release/version.sh version bump tag foo
+@endcode
+
+Of course, any patches in your branches must be provided to
+your customers, and be in conformance with the GPL. In most
+cases you should also work to merge your improvements to the
+mainline tree.
+
+@subsubsection version_tags Development Versions and Tags
+
+Everything except formal releases should have the tag <em>-dev</em>
+in their version number. This helps developers identify reports
+created from non-release versions, and it can be detected and