Next: To make a new
Up: Using the Software Release
Previous: To put a new
  Contents
The develoment cycle before a new production release
The previous two sections illustrate how the development cycle can take
place before a new production release is created. First, as discussed in
section 3.4, developer Foo checks out and works on pkgB
in a test release. When pkgB works to Foo's satisfaction, Foo returns
the package to the pkgB libarian and requests that a new version of
the package be created. Second, as discussed in section 3.5, the
package librarian commits the package back into CVS, tags it with a new
version number, and creates a new version of the package in the official area
using newver. This does not produce any object libraries, or a new
release, which is the topic of the next section. Third, Foo comunicates to
other developers that a new version of the package is available for testing
in the official area. To get the new version of the package and test it,
another developer need only follow the procedure in section 3.4,
checking out the specific version of the package that the librarian created
with Foo's changes. To do this they would create a test release in their area
using newrel -t <base-release> <new-release>,
and then do a
lnkpkg pkgb <tag>
,
or a addpkg pkgB <tag>
,
,
where tag is the
version number. If there is
a special <base-release> that Foo wants used in conjunction with
pkgB, then Foo is obligated to inform the other developers. Once
enough people have used the new version of pkgB, and are happy with
it, the release manager should seriously consider making an official release
with it, so that developers will not need to produce object libraries
themselves in their test release. This is the topic of the next section.
Next: To make a new
Up: Using the Software Release
Previous: To put a new
  Contents
Margaret Votava
2001-02-12