Change most in-tree references from SVN to GIT.

[openocd.git] / doc / manual / release.txt

diff --git a/doc/manual/release.txt b/doc/manual/release.txt
index 2ba652de21ec06f3c4674104bdc95f16fb350375..64dcb811669dc57a7e2a7ea89f4e9fece033e1bb 100644 (file)
--- a/doc/manual/release.txt
+++ b/doc/manual/release.txt
@@ -26,13 +26,13 @@ formats: <code>openocd-\<version\>.{tar.gz,tar.bz2,zip}</code>.  If
 produced properly, these files are suitable for release to the public.
 
 When released for users, these archives present several important
-advantages when contrasted to using the Subversion repository trunk:
+advantages when contrasted to using the git repository:
 
 -# They allow others to package and distribute the code.
 -# They build easier for developers, because they contain
    a working configure script that was produced by the Release Manager.
--# They prevent users from trying a random HEAD revision of the trunk.
--# They free developers from answering questions about trunk breakage.
+-# They prevent users from trying a random work-in-process revision.
+-# They free developers from answering questions about mainline breakage.
 
 Hopefully, this shows several good reasons to produce regular releases,
 but the release processes were developed with some additional design
@@ -64,9 +64,9 @@ the minor version will @a also be zero (<code>y = 0, z = 0</code>).
 After these required numeric components, the version string may contain
 one or more <i>version tags</i>, such as '-rc1' or '-dev'.
 
-The trunk and all branches should have the tag '-dev' in
+Mainline and all branches should have the tag '-dev' in
 their version number.  This tag helps developers identify reports
-created from the Subversion repository, and it can be detected and
+created from the git repository, and it can be detected and
 manipulated by the release script.  Specifically, this tag will be
 removed and re-added during the release process; it should never be
 manipulated by developers in submitted patches.
@@ -159,8 +159,8 @@ 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
-- T minus two weeks: announce pending trunk closure to new work
-- T minus one week: close trunk to new work, begin testing phase
+- T minus two weeks: announce pending mainline closure to new work
+- T minus one week: close mainline to new work, begin testing phase
 - T minus two days: call for final bug fixes
 - T minus one day: produce -rc packages and distribute to testers
 - T minus one hour: produce final packages and post on-line
@@ -212,20 +212,20 @@ 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):
+-# Produce final patches to mainline (or release branch):
   -# 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 -dev tag from package version in configure.in:
-    - For major/minor releases, remove version tag from trunk, @a or
+    - For major/minor releases, remove version tag from mainline, @a or
     - For bug-fix releases, remove version tag from release branch.
--# Branch or tag the required tree in the Subversion repository:
+-# Branch or tag the required tree in the git repository:
   - Tags and branches for releases must be named consistently: @par
     "${PACKAGE_TARNAME}-${PACKAGE_VERSION}"
-  - For a major/minor release from the main trunk, the code should be
-    branched and tagged in the repository:
+  - For a major/minor release from the mainline, the code should be
+    tagged in the repository:
 @verbatim
 svn cp .../trunk .../branches/${RELEASE_BRANCH}
 svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@@ -238,9 +238,9 @@ svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
 -# 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 major/minor release from the mainline:
+    -# Bump major or minor package version in mainline.
+    -# Restore version tag to mainline.
   - For bug-fix releases from a release branch:
     -# Bump bug-fix version in release branch.
     -# Restore version tag to release branch.
@@ -310,7 +310,7 @@ Packaging Commands:
 
 Repository Commands:
   commit        Perform branch and tag, as appropriate for the version.
-  branch        Create a release branch from the project trunk.
+  branch        Create a release branch from project mainline.
   tag           Create a tag for the current release branch.
 
 Other Commands:
@@ -338,7 +338,7 @@ affect its behavior:
   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
+it will make permanent changes to the git repository that
 cannot be undone.
 
 @subsection releasescriptenv Release Script Environment
@@ -371,7 +371,7 @@ use to run the @c release.sh script to produce a minor release.
 If the proper environment has been set, the following steps will produce
 a new minor release:
 
--# Check out (or update) the project trunk from the berliOS repository:
+-# Check out (or update) mainline from the repository:
 @code
 svn checkout "${SVN_URL}/trunk" openocd-trunk
 @endcode