305N/ACopyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
305N/ACopyright (C) 2000-2003 Internet Software Consortium.
305N/A$Id: release,v 1.59 2004/03/13 04:08:07 sra Exp $
305N/APreparing a bind9 release
305N/AHere's a rough outline of the steps to follow in preparing a new bind9
305N/A - Update the README file
305N/A - Send the new README file to webteam@nominum.com at least 48
305N/A hours prior to the planned release and ask them to prepare
305N/A the web pages for the new version. If there have been only
305N/A minor changes, send context diffs relative to the previous
305N/A - Do a "cvs update" to check that all changes have been committed.
305N/A - Verify that the file "version" contains the correct version
305N/A number (it should have been incremented after the
305N/A - If building from a release branch, check that any important
305N/A bug fixes made on the mainline since the last release have
305N/A been pulled up. You can do this by comparing the CHANGES
305N/A running the script from a mainline tree:
305N/A This will list all bug fixes on the mainline that are not
305N/A on the 9.2 release branch.
305N/A - Before creating a new release branch, update the lib/*/api files
305N/A as needed. See the libtool info file for information about what
305N/A the various numbers mean.
305N/A shows a clean build and test status for all supported
305N/A systems and that the tests are actually being run on the
305N/A version being released (the version can be found in the
305N/A page behind the "Source tar build" link).
305N/A produce compile errors.
305N/A - Regenerate the documentation by running "make man" (mainline/9.2)
305N/A and commit it. Note that not all machines have the
305N/A necessary XML tools, but at least trebuchet, cuba,
305N/A and Scanner's machine do. Commit any files that were
305N/A - Update the copyrights. According to tale:
305N/A Go to the root of the source tree.
305N/A The scripts need to be run from there; they reference the util
305N/A subdirectory internally.
305N/A ... [I prefer to check out a fresh source tree --gson]
305N/A ... examine output, particularly any files with the "?" type, and
305N/A ... examine output, edit as necessary. mail me about anything that
305N/A ... the script should have been able to do itself. :-)
305N/A $ cvs ci -m'update_copyrights'
305N/A - Announce a CVS freeze if doing an alpha or beta release from
305N/A the mainline, or stop doing pullups if building from a release branch.
305N/A obscure build options work. This script may need some hacking if run
305N/A on anything other than NetBSD. Save the output (it's big) and look
305N/A for error and warning messages.
305N/A cd $top_of_mainline_tree
305N/A Alteratively, you can do this after building the kit, by giving
- If you can (= your system is similar enough to the one Tale is using),
check the header files for cruft by running the command
[ This step is quite imperfect and should probably be skipped
- Ensure that the JPNIC patch applies cleanly:
If you don't have the "iconv" library, you need to get it from
If you're reading this part of these instructions in order to generate
a version of the patch for a new release, you'll need to pick a
version of the patch from some prior release to use as a starting
point. In general, the patch corresponding to the most recent
prior release will be the best starting point.
All hunks should have applied successfully with no offset or fuzz.
If all succeeded but some were offset or had fuzz, the patch will be
regenerated at the end of this stage.
Note that two of the files which the patch attempts to update
(configure and
config.h.in) are generated automatically. When
generating a new patch, the old version of the patch may not apply
correctly to these files, but that's ok so long as the patch does
apply correctly to the source files from which these files are
generated. The steps below will regenerate these files.
[ Sample on freebsd -- formerly used giconv, now uses iconv ]
$ cd ../../.. ; : cd back to top level
$ autoconf ; : regenerate configure
... should cleanly compile
... should cleanly compile
Generate a fresh copy of the diffs:
$ files=`awk '/^Index:/ && NF == 2 {print $2}' $patchd/$old_patch`
$ missing=`cvs log -R $files 2>&1 >
/dev/null | \
awk '/^cvs log: nothing known about/ {print $6}'`
do echo Index: $i; diff -u
/dev/null $i; done >$patchd/$new_patch
$ cvs -f diff -U 2 -N $files >>$patchd/$new_patch
[ Add comment at head of new patch file ]
$ cvs add -ko $patchd/$new_patch
$ cvs ci $patchd/$new_patch
- 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.
# kill both the keep-running script and named itself
# kill both keep-running scripts and both named9:s
- 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"