docs: update release docs to use configure.ac
authorSpencer Oliver <spen@spen-soft.co.uk>
Tue, 20 Mar 2012 21:21:15 +0000 (21:21 +0000)
committerSpencer Oliver <spen@spen-soft.co.uk>
Fri, 30 Mar 2012 15:55:21 +0000 (15:55 +0000)
Change-Id: I7b52ad1c3744a82832c5b55898bf47607e24d03e
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/538
Tested-by: jenkins
doc/manual/release.txt

index d26ffd60a40e87b9d9582a9b3f5ada621ac9d80f..8611bb7b0920531e7cb6ae4daf0e73d151dee857 100644 (file)
@@ -107,14 +107,14 @@ original code base.  Each packager release should have a unique
 version.
 
 For example, the following command will add a 'foo' tag to the
 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
+configure.ac 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
 
 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
+This command will modify the configure.ac 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
 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
@@ -296,7 +296,7 @@ The following steps should be followed to produce each release:
       be needed (except to seed the process for the next release, or maybe
       if a significant and longstanding bug is fixed late in the RC phase).
   -# Bump library version if our API changed (not yet required)
       be needed (except to seed the process for the next release, or maybe
       if a significant and longstanding bug is fixed late in the RC phase).
   -# Bump library version if our API changed (not yet required)
-  -# Update and commit the final package version in @c configure.in:
+  -# Update and commit the final package version in @c configure.ac:
      (The <code>tools/release/version.sh</code> script might help ensure
      the versions are named properly.):
     -# Remove @c -dev tag.
      (The <code>tools/release/version.sh</code> script might help ensure
      the versions are named properly.):
     -# Remove @c -dev tag.
@@ -306,7 +306,7 @@ The following steps should be followed to produce each release:
       - If producing the next RC in a series, bump the rc number
     -# Commit that version change, with a good descriptive comment.
   -# Create a git tag for the final commit, with a tag name matching
       - If producing the next RC in a series, bump the rc number
     -# Commit that version change, with a good descriptive comment.
   -# Create a git tag for the final commit, with a tag name matching
-     the version string in <code>configure.in</code> (including <em>-rcN</em>
+     the version string in <code>configure.ac</code> (including <em>-rcN</em>
      where relevant):
 @verbatim
 PACKAGE_VERSION="x.y.z"
      where relevant):
 @verbatim
 PACKAGE_VERSION="x.y.z"
@@ -322,7 +322,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
      the last ones to be included in the release being made.
 -# Produce the release files, using the local clone of the source
   tree which holds the release's tag and updated version in
      the last ones to be included in the release being made.
 -# Produce the release files, using the local clone of the source
   tree which holds the release's tag and updated version in
-  @c configure.in ... this is used only to produce the release, and
+  @c configure.ac ... this is used only to produce the release, and
   all files should already be properly checked out.
   -# Run <code>tools/release.sh package</code> to produce the
        source archives.  This automatically bootstraps and
   all files should already be properly checked out.
   -# Run <code>tools/release.sh package</code> to produce the
        source archives.  This automatically bootstraps and
@@ -373,7 +373,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
 -# 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.)
 -# 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.in file:
+  - 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
      - 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
@@ -396,7 +396,7 @@ To start a bug-fix release branch:
 -# Create a new branch, starting from a major or
    minor release tag
 -# Restore @c -dev version tag.
 -# Create a new branch, starting from a major or
    minor release tag
 -# Restore @c -dev version tag.
--# Bump micro version number in configure.in
+-# 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.)
 -# 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.)

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)