Update Release Script documentation to reflect current implementation.
[openocd.git] / doc / manual / release.txt
index 45652c2eeee3a81c285779aad529ad4937ec37f9..c70697178f34b95c0e80173c03fee2e77bd8b11e 100644 (file)
@@ -190,19 +190,14 @@ Even with the release script, some steps require clear user intervention
 The following steps should be followed to produce each release:
 
 -# Produce final patches to the trunk (or release branch):
-  -# add NEWS item to describe the release changes? (not ready for 0.2.0)
-    - the community should try to help produce this material
-    - can be used to automatically post "blurbs" about the project.
+  -# 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.
   -# bump library version if our API changed (not yet required)
   -# Remove -in-development tag from package version:
-    - For major/minor releases, remove version tag from trunk.
+    - For major/minor releases, remove version tag from trunk, @a or
     - For bug-fix releases, remove version tag from release branch.
--# Produce and verify the binary packages:
-  -# Start with a clean working copy, used for producing releases only.
-  -# produce a ChangeLog for the release (using svn2cl).
-  -# bootstrap, configure, and build the package.
-  -# run 'make distcheck' to produce the distribution archives.
-  -# run 'make maintainer-clean'; verify the repository is empty again.
 -# Branch or tag the required tree in the Subversion repository:
   - Tags and branches for releases must be named consistently: @par
     "${PACKAGE_TARNAME}-${PACKAGE_VERSION}"
@@ -218,23 +213,37 @@ svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
 svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
 @endverbatim
 -# Prepare to resume normal development activities:
+  - Archive @c NEWS file as <code>doc/news/NEWS-${PACKAGE_VERSION}</code>.
+  - Create a new @c NEWS file for the next release
   - For major/minor release from the trunk:
     -# Bump major or minor package version in trunk.
     -# Restore version tag to trunk and release branch.
   - For bug-fix releases from a release branch:
     -# Bump bug-fix version in release branch.
     -# Restore version tag to release branch.
+-# 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).
+  -# @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.
 -# 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:
-    - NEWS: to provide a blurb for each release (not yet used)
-    - ChangeLog: to show exactly what has been changed
+    - @c NEWS: to provide a blurb for each release
+    - @c ChangeLog: to show exactly what has been changed
     - User Guide, Developer Manual: to allow easy on-line viewing
 -# Upload packages and post announcements of their availability:
-  -# Release packages into files section of berliOS project site.
+  -# Release packages into files section of berliOS project site:
+     -# Create the new release for the new version.
+     -# Provide @c NEWS and ChangeLog files, as requested.
+     -# Upload files via FTP to ftp://ftp.berlios.de/incoming/
+     -# Edit descriptions for each file.
+     -# Send E-mail Release Notice
   -# Post announcement e-mail to the openocd-development list.
   -# Announce updates on freshmeat.net and other trackers.
-  -# Submit big NEWS updates to news feeds (e.g. Digg, Reddit, etc.).
+  -# Submit big updates to news feeds (e.g. Digg, Reddit, etc.).
 
 @section releasescript The Release Script
 
@@ -258,7 +267,7 @@ In addition, support for '-rc' releases needs to be added.
 
 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.
@@ -294,6 +303,20 @@ WARNING: This script should be used by the Release Manager ONLY.
 
 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
@@ -301,18 +324,13 @@ affect its behavior:
 
 - @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:
@@ -377,7 +395,7 @@ patching of the configure script.  The final release script should be
 able to manage most steps of the processes.  The steps requiring user
 input could be guided by an "assistant" that walks the Release Manager
 through the process from beginning to end, performing basic sanity
-checks on their various inputs (e.g. the NEWS blurb).
+checks on their various inputs (e.g. the @c NEWS blurb).
 
  */
 /** @file

Linking to existing account procedure

If you already have an account and want to add another login method you MUST first sign in with your existing account and then change URL to read https://review.openocd.org/login/?link to get to this page again but this time it'll work for linking. Thank you.

SSH host keys fingerprints

1024 SHA256:YKx8b7u5ZWdcbp7/4AeXNaqElP49m6QrwfXaqQGJAOk gerrit-code-review@openocd.zylin.com (DSA)
384 SHA256:jHIbSQa4REvwCFG4cq5LBlBLxmxSqelQPem/EXIrxjk gerrit-code-review@openocd.org (ECDSA)
521 SHA256:UAOPYkU9Fjtcao0Ul/Rrlnj/OsQvt+pgdYSZ4jOYdgs gerrit-code-review@openocd.org (ECDSA)
256 SHA256:A13M5QlnozFOvTllybRZH6vm7iSt0XLxbA48yfc2yfY gerrit-code-review@openocd.org (ECDSA)
256 SHA256:spYMBqEYoAOtK7yZBrcwE8ZpYt6b68Cfh9yEVetvbXg gerrit-code-review@openocd.org (ED25519)
+--[ED25519 256]--+
|=..              |
|+o..   .         |
|*.o   . .        |
|+B . . .         |
|Bo. = o S        |
|Oo.+ + =         |
|oB=.* = . o      |
| =+=.+   + E     |
|. .=o   . o      |
+----[SHA256]-----+
2048 SHA256:0Onrb7/PHjpo6iVZ7xQX2riKN83FJ3KGU0TvI0TaFG4 gerrit-code-review@openocd.zylin.com (RSA)