The OpenOCD release process must be carried out on a periodic basis, so
the project can realize the benefits presented in answer to the question,
-@ref releasewhy.
+@ref releasewhy.
Starting with the 0.2.0 release, the OpenOCD project should produce a
new minor release every month or two, with a major release once a year.
release. This section presents guidelines for scheduling key points
where the community must be informed of changing conditions.
-If T is the time of the next release, then the following schedule
+If T is the time of the next release, then the following schedule
might describe some of the key milestones of the new release cycle:
- T minus one month: start of new development cycle
The following steps should be followed to produce each release:
-# Produce final patches to the trunk (or release branch):
- -# Finalize @c NEWS file to describe the changes in the release
+ -# Finalize @c NEWS file to describe the changes in the release
- This file is Used to automatically post "blurbs" about the project.
- This material should be produced during the development cycle.
- Add a new item for each @c NEWS-worthy contribution, when committed.
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@endverbatim
- For bug-fix releases produced in their respective branch, a tag
- should be created in the repository:
+ should be created in the repository:
@verbatim
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@endverbatim
-# Produce the package source archives:
-# Start with a clean working copy, used for producing releases only.
-# Switch to release tag branch: svn switch .../${RELEASE_TAG}
- -# produce a ChangeLog for the release (using svn2cl).
+ -# Produce a ChangeLog for the release (using svn2cl).
-# @c bootstrap, @c configure, and @c make the package.
-# Run <code>make distcheck</code> to produce the distribution archives.
-# Run <code>make maintainer-clean</code> verify the repository is empty.
+ -# Create signature files using md5sum, sha1sum, etc.
-# Publish documentation for the release:
- Allow users to access the documentation for each of our releases.
- Place static copies of the following files on the project website:
The following output was taken from the release script:
@verbatim
-usage: tools/release.sh <command>
+usage: tools/release.sh [options] <command>
Main Commands:
info Show a summary of the next pending release.
Run <code>tools/release.sh help</code> for current command support.
+@subsection releasescriptenv Release Script Options
+
+The @c release.sh script recognizes some command-line options that
+affect its behavior:
+
+- @c --live : Use this option to perform a live release.
+ When this option has been given, the release commands will affect
+ the repository; otherwise, the script reports the actions to take,
+ and it produces archives that are unsuitable for public release.
+
+@note Only the Release Manager should use the @c --live option, as
+it will make permanent changes to the Subversion repository that
+cannot be undone.
+
@subsection releasescriptenv Release Script Environment
The @c release.sh script recognizes some environment variables which
- @c CONFIG_OPTS : Passed as options to the configure script.
- @c MAKE_OPTS : Passed as options to the 'make' processes.
-- @c RELEASE_DRY_RUN : Set this to null to perform the live release.
- Unless this variable has been (un)set, the release commands will not
- affect the repository.
-
-Proper option handling should be added to set these variables in script.
@section releasetutorial Release Tutorials
This section provides tutorials for using the Release Script to perform
common release tasks.
-@subsection releasetutorialminor Minor Release Tutorial
+@subsection releasetutorialsetup Release Tutorial Setup
The tutorials in this section assume the following environment
variables have been set properly: