zcy
/
tinyriscv-openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Release docs: fix notes 

We currently do something unusual:  version codes in config.in get
updated after the release, which means that "git describe" won't
match up to development version labels.  Comment that trouble spot.

We can fix this by switching away from the major/minor/micro type
release numbering, as various other projects have done.  The major
numbers basically don't tend to change, and doing a good job with
micro versions is so annoying that they rarely change either.
__archive__
David Brownell 2009-11-04 17:49:06 -08:00
parent 6455ae4a59
commit ecd9c0d8bf
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/manual/release.txt
View File

@ -156,7 +156,8 @@ can be useful when tracking down bugs.
(Note that at this writing, the tags do not directly (Note that at this writing, the tags do not directly
correspond to <code>git describe</code> output. The correspond to <code>git describe</code> output. The
hash ID can be used with <code>git show</code>, but hash ID can be used with <code>git show</code>, but
the preceding segments can't.) the relevant repository tag isn't <em>0.3.0-rc1-dev</em>;
this might change in the future.)
@section releasewho Release Manager @section releasewho Release Manager
@ -293,17 +294,21 @@ The following steps should be followed to produce each release:
- If producing the next RC in a series, bump the rc number - If producing the next RC in a series, bump the rc number
-# Commit that version change. -# Commit that version change.
-# Create a git tag for the final commit, with a tag name matching -# Create a git tag for the final commit, with a tag name matching
the version string in <code>configure.in</code>: the version string in <code>configure.in</code> (including <em>-rcN</em>
where relevant):
@verbatim @verbatim
PACKAGE_VERSION="x.y.z" PACKAGE_VERSION="x.y.z"
PACKAGE_TAG="v${PACKAGE_VERSION}" PACKAGE_TAG="v${PACKAGE_VERSION}"
git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}" git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
@endverbatim @endverbatim
-# Prepare to resume normal development on mainline: -# Prepare to resume normal development on mainline (major or minor release)
- Restore @c -dev version tag. - Update the version label
- To start a new major (or minor) release cycle on the @c master branch: - Restore @c -dev version tag.
- Archive @c NEWS file as "<code>doc/news/NEWS-${PACKAGE_VERSION}</code>". - For a new minor release cycle, increment the release's minor number
- Create a new @c NEWS file for the next release - For a new major release cycle, increment the release's major number
and zero its minor number
- Archive @c NEWS file as "<code>doc/news/NEWS-${PACKAGE_VERSION}</code>".
- Create a new @c NEWS file for the next release
- Commit those changes, and push the commit and the release tag - Commit those changes, and push the commit and the release tag
to mainline. to mainline.
-# Produce the package source archives: -# Produce the package source archives: