diff options
Diffstat (limited to 'doc/manual/release.txt')
-rw-r--r-- | doc/manual/release.txt | 36 |
1 files changed, 18 insertions, 18 deletions
diff --git a/doc/manual/release.txt b/doc/manual/release.txt index 2ba652d..64dcb81 100644 --- 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 |