- -# Announce updates on freshmeat.net and other trackers.
- -# Submit big updates to news feeds (e.g. Digg, Reddit, etc.).
-
-@section releasescript The Release Script
-
-Many of the processes described in the last section are no longer
-entrusted to humans. Instead, the @c release.sh script provides
-automation of the mechanical steps.
-
-Presently, the @c release.sh script automates steps 1(c) through 4,
-allowing the Release Manager from perform these tasks in easy steps.
-
-The following task still need to be automated:
-
-- Step 5: produce documentation for website using released source archive.
-- Step 6(a): package archive upload process.
-- Step 6(b): package announcement e-mail process.
-- Step 6(c): post files and announce them using releaseforge.
-
-In addition, support for '-rc' releases needs to be added.
+ -# optionally:
+ -# Post an update on the OpenOCD blog.
+ -# Announce updates on freshmeat.net and other trackers.
+ -# Submit updates to news feeds (e.g. Digg, Reddit, etc.).
+-# Resume normal development on mainline, by opening the merge window for
+ the next major or minor release cycle. (You might want to do this
+ before all the release bits are fully published.)
+ - Update the version label in the @c configure.ac file:
+ - Restore @c -dev version tag.
+ - For a new minor release cycle, increment the release's minor number
+ - 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.
+ - Push all the updates to mainline.
+ - Last updates for the release, including the release tag (you
+ will need to "git push --tags").
+ - Updates opening the merge window
+ - At this point, it's OK for commiters to start pushing changes
+ which have been held off until the next release. (Any bugfixes to
+ this release will be against a bug-fix release branch starting from
+ the commit you tagged as this release, not mainline.)
+ - Announce to the openocd-development list. Ideally, you will also
+ be able to say who is managing the next release cycle.
+
+To start a bug-fix release branch:
+-# Create a new branch, starting from a major or
+ minor release tag
+-# Restore @c -dev version tag.
+-# Bump micro version number in configure.ac
+-# Backport bugfix patches from mainline into that branch.
+ (Always be sure mainline has the fix first, so it's hard
+ to just lose a bugfix.)
+-# Commit and push those patches.
+-# When desired, release as above ... except note that the next
+ release of a bugfix branch is never a new major or minor release