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
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.
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
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}
-# 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.
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:
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
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
projects / openocd / blobdiff