2N/AaCopyright (C) 2000, 2001 Internet Software Consortium.
2N/A$Id: release,v 1.51 2001/11/25 01:56:01 gson Exp $
2N/APreparing a bind9 release
2N/AHere's a rough outline of the steps to follow in preparing a new bind9
2N/A - Update the README file
2N/A - Send the new README file to webteam@nominum.com at least 48
2N/A hours prior to the planned release and ask them to prepare
2N/A the web pages for the new version. If there have been only
2N/A minor changes, send context diffs relative to the previous
2N/A - Do a "cvs update" to check that all changes have been committed.
2N/A - Verify that the file "version" contains the correct version
2N/A number (it should have been incremented after the
2N/A - Before creating a new release branch, update the lib/*/api files
2N/A as needed. See the libtool info file for information about what
2N/A the various numbers mean.
2N/A - If building from a release branch, check that any important
2N/A bug fixes made on the mainline since the last release have
2N/A been pulled up. You can do this by comparing the CHANGES
2N/A running the script from a mainline tree:
2N/A This will list all bug fixes on the mainline that are not
2N/A on the 9.2 release branch.
2N/A shows a clean build and test status for all supported
2N/A systems and that the tests are actually being run on the
2N/A version being released (the version can be found in the
2N/A page behind the "Source tar build" link).
2N/A produce compile errors.
2N/A - Regenerate the documentation by running "make man" (mainline/9.2)
2N/A and commit it. Note that not all machines have the
2N/A necessary XML tools, but at least trebuchet, cuba,
2N/A and Scanner's machine do. Commit any files that were
2N/A - Verify that the documents in
doc/misc are up-to-date.
2N/A - Update the copyrights. According to tale:
2N/A Go to the root of the source tree.
2N/A The scripts need to be run from there; they reference the util
2N/A subdirectory internally.
2N/A ... [I prefer to check out a fresh source tree --gson]
2N/A ... examine output, particularly any files with the "?" type, and
2N/A ... examine output, edit as necessary. mail me about anything that
2N/A ... the script should have been able to do itself. :-)
2N/A $ cvs ci -m'update_copyrights'
2N/A - Announce a CVS freeze if doing an alpha or beta release from
2N/A the mainline, or stop doing pullups if building from a release branch.
2N/A obscure build options work. This script may need some hacking if run
2N/A on anything other than NetBSD. Save the output (it's big) and look
2N/A for error and warning messages.
2N/A cd $top_of_mainline_tree
2N/A Alteratively, you can do this after building the kit, by giving
2N/A - If you can (= your system is similar enough to the one Tale is using),
2N/A check the header files for cruft by running the command
2N/A [ This step is quite imperfect and should probably be skipped
2N/A - Ensure that the JPNIC patch applies cleanly:
2N/A If you don't have the "iconv" library, you need to get it from
2N/A All hunks should have applied successfully with no offset or fuzz.
2N/A If all succeeded but some were offset or had fuzz, the patch will be
2N/A regenerated at the end of this stage.
2N/A [ Sample on netbsd ... ]
2N/A $ cd ../../.. ; : cd back to top level
2N/A ... should cleanly compile
2N/A ... should cleanly compile
2N/A Generate a fresh copy of the diffs:
- Add a marker line like " --- 9.0.0rc10 released ---"
- Tag the CVS source tree with the final tag, as in
"cvs rtag v9_0_0rc1 bind9" (mainline) or
"cvs rtag -r v9_2 v9_2_0rc10 bind9" (release branch).
- Build the release kit. This procedure differs
between the 9.0 release branch and later versions.
On the 9.0 release branch,
cvs export -r v9_0_0rc10 bind9
On the 9.[1-2] release branch or mainline, use the
- Build bind9 from the kit on ns-ext (phred)
and ns-int (rc), install it, and let it run for
a day keeping an eye on it for any problems.
- If you can, try resolving some IPv6 addresses and
- If problems are found at this stage, fix them, move the
release tag up using "rtag -F", and respin the kit.
- Sign the distribution files with the ISC signing PGP key
and fix the permissions on the signature file:
- Verify the PGP signature:
(Look for the words "Good signature" in the output.)
- If there is a companion binary kit for NT, sign it and verify the
pgp -sba BIND$
ver.zip -u 0x51BAB2ED
- Prepare a release announcement based on the previous one.
- Copy the distribution and PGP signature files to the FTP site:
- If there is a companion binary kit for NT, copy it, too:
- Download using FTP (or a web browser) using the URLs in the release
announcement and verify the PGP signature again
- Ask webteam@nominum.com to publish the updated web pages
- When the web pages are up, announce the release on
- Increment the version in the file "version"