release revision 0c27b3fe77ac1d5094ba3521e8142d9e7973133f
Copyright (C) 2000-2007, 2009, 2014, 2016 Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
$Id: release,v 1.74 2009/08/06 23:47:44 tbox Exp $
Preparing a bind9 release
Here's a rough outline of the steps to follow in preparing a new bind9
release.
- Update the README file
- Send the new README file to webteam@nominum.com at least 48
hours prior to the planned release and ask them to prepare
the web pages for the new version. If there have been only
minor changes, send context diffs relative to the previous
release instead.
- Do a "cvs update" to check that all changes have been committed.
- Verify that the file "version" contains the correct version
number (it should have been incremented after the
previous release)
- If building from a release branch, check that any important
bug fixes made on the mainline since the last release have
been pulled up. You can do this by comparing the CHANGES
files using the util/check-pullups.pl script. For example,
running the script from a mainline tree:
perl util/check-pullups.pl CHANGES ../9.2/CHANGES ../9.2/EXCLUDED
This will list all bug fixes on the mainline that are not
on the 9.2 release branch.
- Before creating a new release branch, update the lib/*/api files
as needed. See the libtool info file for information about what
the various numbers mean.
cvs rdiff -r <last_release> -r <branch/HEAD> bind9/lib > diff
cvs rdiff -r v9_4_0rc2 -r v9_4 bind9/lib > diff
- Check that https://internal.isc.org/bind-build/
shows a clean build and test status for all supported
systems and that the tests are actually being run on the
version being released (the version can be found in the
page behind the "Source tar build" link).
- Check that running "make all_tests" in bin/tests does not
produce compile errors.
- Regenerate the documentation by running "make man" (mainline/9.2)
or by running genhtml.sh in doc/arm (9.1 release branch)
and commit it. Note that not all machines have the
necessary XML tools, but at least trebuchet, cuba,
and Scanner's machine do. Commit any files that were
regenerated.
Most of this has now been automated, only doc/arm/ARM.pdf will
not be committed:
ssh tbox@docs.lab.isc.org
run this command from crontab.
1 1 * * * /usr/bin/lockf -s -t 0 /udir/tbox/bind9-documents/regenerate.lock /udir/tbox/bind9-documents/regenerate
Check to see if the ARM has changed since the last release
and if it has commit doc/arm/ARM.pdf.
cvs rdiff -r v9_6_1 -r v9_6 bind9/doc/arm
cvs commit doc/arm/ARM.pdf
- Verify that the documents in doc/misc are up-to-date.
- Update the copyrights.
ssh tbox@cvs.isc.org
run these two command from the crontab
#
# Merge and Update copyrights
#
30 23 * * * /usr/bin/lockf -s -t 3600 /udir/tbox/tarballs/build-tarballs.lock /bin/sh /udir/tbox/tarballs/mergecopyrights
45 23 * * * /usr/bin/lockf -s -t 3600 /udir/tbox/updatecopyrights/updatecopyrights.lock /bin/sh /udir/tbox/updatecopyrights/updatecopyrights
When tbox@cvs.isc.org is not available:
Go to the root of the source tree.
The scripts need to be run from there; they reference the util
subdirectory internally.
$ make distclean
... [I prefer to check out a fresh source tree --gson]
$ perl util/merge_copyrights
... examine output, particularly any files with the "?" type, and
... then edit util/newcopyrights if necessary
$ cvs ci -m'merge_copyrights' util/copyrights
$ perl util/update_copyrights < util/copyrights
$ cvs diff
... examine output, edit as necessary. mail me about anything that
... the script should have been able to do itself. :-)
$ cvs ci -m'update_copyrights'
- Announce a CVS freeze if doing an alpha or beta release from
the mainline, or stop doing pullups if building from a release branch.
- Run util/altbuild.sh. This is to make sure that
builds using libtool, separate source/object directories, and other
obscure build options work. This script may need some hacking if run
on anything other than NetBSD. Save the output (it's big) and look
for error and warning messages.
cd $top_of_mainline_tree
sh util/altbuild.sh v9_0
or
cd $top_of_9_1_tree
sh util/altbuild.sh v9_1
Alteratively, you can do this after building the kit, by giving
the kit .tar.gz file as an argument to altbuild.sh instad of
the CVS tag.
- 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
for now -- Tale ]
find lib -name '*.h' -print | xargs perl util/check-includes.pl
- Ensure that the JPNIC patch applies cleanly (9.2 and 9.3):
If you don't have the "iconv" library, you need to get it from
http://clisp.cons.org/~haible/packages-libiconv.html and install it.
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.
$ patch -p0 < contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.x.y-patch \
> patch.out 2>&1
$ egrep Hunk patch.out
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 netbsd ... ]
$ CFLAGS=-I/usr/local/include ./configure '--with-iconv=-L/usr/local/lib -liconv'
[ Sample on freebsd -- formerly used giconv, now uses iconv ]
./configure --with-iconv-include=/usr/local/include \
'--with-iconv=-L/usr/local/lib -liconv'
$ make
$ cd ../../.. ; : cd back to top level
$ autoheader ; : regenerate config.h.in
$ autoconf ; : regenerate configure
$ ./configure
$ make
... should cleanly compile
$ (cd bin/dig ; rm host.1 dig.1 ; make host.1 dig.1 ; cvs update host.1 dig.1 )
$ make distclean
$ rm -rf /tmp/idn
$ mkdir -p /tmp/idn/lib /tmp/idn/include
$ ./configure --with-idn=/tmp/idn --with-iconv="-L/usr/local/lib -liconv"
... should cleanly compile
[ Some tests will be added to bin/tests/system to validate operation. ]
Generate a fresh copy of the diffs:
$ patchd=$idn/patch/bind9
$ old_patch=bind-9.x.y-patch
$ new_patch=bind-9.x.z-patch
$ files=`awk '/^Index:/ && NF == 2 {print $2}' $patchd/$old_patch`
$ missing=`cvs status $files | awk '/Status: Unknown/ { print $2; }'`
$ sed '/^Index:/,$d' $patchd/$old_patch > $patchd/$new_patch
$ for i in $missing; \
do echo Index: $i; diff -u /dev/null $i; done >> $patchd/$new_patch
$ cvs -f diff -U 2 -N $files >> $patchd/$new_patch
$ cvs add -ko $patchd/$new_patch
$ cvs ci $patchd/$new_patch
$ cvs update -C
$ rm README.idnkit
$ make distclean
- Add a marker line like " --- 9.0.0rc10 released ---"
to the CHANGES file.
- 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,
cd <temporary directory>
cvs export -r v9_0_0rc10 bind9
cd bind9
sh configure
make kit
On the 9.[1-2] release branch or mainline, use the
"util/kit.sh" script.
- 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.
ssh phred.isc.org
ver=9.2.0
scp rc.isc.org:bind-$ver.tar.gz .
gunzip <bind-$ver.tar.gz | tar xfv -
cd bind-$ver
sh configure
make
su
make install
ps -elf | grep named
# kill both the keep-running script and named itself
/var/named/keep-running ns-ext &
ssh rc
ver=9.2.0
gunzip <bind-$ver.tar.gz | tar xfv -
cd bind-$ver
sh configure
make
su
make install
ps -elf | grep named
# kill both keep-running scripts and both named9:s
/var/named/keep-running9 rc-res1 &
/var/named/keep-running9 ns-int &
- If you can, try resolving some IPv6 addresses and
doing queries over IPv6.
- 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:
ver=9.2.0
pgp -sba bind-$ver.tar.gz -u 0x51BAB2ED
chmod 644 bind-$ver.tar.gz.asc
- Verify the PGP signature:
pgp bind-$ver.tar.gz.asc bind-$ver.tar.gz
(Look for the words "Good signature" in the output.)
- If there is a companion binary kit for NT, sign it and verify the
signature:
pgp -sba BIND$ver.zip -u 0x51BAB2ED
chmod 644 BIND$ver.zip.asc
pgp BIND$ver.zip.asc BIND$ver.zip
- Prepare a release announcement based on the previous one.
- Copy the distribution and PGP signature files to the FTP site:
ssh -n isrv4.pa.vix.com "mkdir /udir/ftp/isc/bind9/$ver"
scp bind-$ver.tar.gz bind-$ver.tar.gz.asc \
- If there is a companion binary kit for NT, copy it, too:
ssh -n isrv4.pa.vix.com "mkdir /udir/ftp/isc/bind/contrib/ntbind-$ver"
scp BIND$ver.zip BIND$ver.zip.asc \
- 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
bind-announce@isc.org
- Increment the version in the file "version", "configure.in" and
- Resume doing pullups