next up previous contents
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 up previous contents
Next: To make a new Up: Using the Software Release Previous: To put a new   Contents
Margaret Votava
2001-02-12