Owner: jreed

Date next review scheduled: January 13, 2012

This page documents the release engineering schedule and processes for development, snapshot-style releases for BIND 10. See ReleaseEngineering for the procedures for the stable production releases.

These development releases don't go through the alpha, beta, release candidate stages of quality assurance. Basically they are just snapshots of what currently is in master.

  • define schedule for freeze of "new" code development work (then to focus on reviews) and for freeze of code commits. These may be seven days before and 24 hours before respectively.
  • every new interface, new configuration, operational change must be described in documentation
  • make sure we don't have any tickets of "High Defect Severity" open

or sensitive

  • make sure there are not any new autoreconf warnings

(TODO: automake check for this)

  • open web-request ticket a day before public announcement to give them a heads up
  • check if man pages are up-to-date for spec files.
  • check that generated manuals are up-to-date.
  • review open tickets, especially for the release itself
  • check versions for individual components (like version in src/bin/bind10/ have been bumped if needed.
  • make sure bind10-messages.xml is up-to-date
  • check authors.bind is updated if needed
  • real world usage tests
  • update README as applicable
  • make sure ChangeLog is up-to-date and correct. Add released date to top.
  • before branch make sure man pages and guide are generated and committed
  • verify library versioning (TODO: automate this)
  • very temporary code freeze and branching for new release.
  • let developers know freeze is over
  • update version in (in branch) to date of the planned release
  • regenerate guide and messages so have correct version
  • make sure guide has correct version
  • make sure bind10-messages.html is up-to-date and has correct version.
  • disable features from build and from tarball for new branch that shouldn't be released (but still in master)
  • automated testing for new tag/branch by adding to top of BUILD_QUEUE (later: daily snapshots and benchmark reports too)
  • build tarball by running distcheck (within the unmodified branch)
  • write announcement email, not committed to tree. This includes part of ChangeLog. Send draft to a couple reviewers.
  • script to untar tarball, build, run tests, and run and verify
  • make sure that "make clean" and "make distclean" work correctly (note that distcheck target does the clean testing too)
  • check with "git status" that no files are left around (TODO: automate this)
  • make sure runs from run_ in source tree;

use make systest for some of this

  • copy new tarball to personal public_html for quick testing by others on team (point to it in jabber and bind10-dev)
  • do builds of tarball on Linux and another system
  • verify tarball extraction
  • verify tarball doesn't have junk files in it (like .svn or .o$ or others)
  • verify tarball has correct versions and generated html guide and man pages
  • test running the system with automated scripts
  • verify API installation by compiling and testing outside code (like host outside of tree)
  • upload file to bikeshed for PGP signer
  • send request to signers address for the official PGP signatures. It should contain sha256 hash of the file(s).

(Note: This may take over 15 hours.)

  • verify signatures (after received)
  • close the RT bugs ticket used for the signing request
  • copy reviewed announcement to the release directory on bikeshed
  • open OPS ticket to get FTP files copied over to FTP server:

/ftp/isc/bind10/devel-${VERSION} So it is at$VERSION/bind10-devel-$VERSION.tar.gz

(NOTE: also make sure symlink is in place.)

  • once FTP files in place, test ftp download
  • check announcement email to make sure its URLs work and test ftp download and verify PGP signature(s).
  • upload updated guide (HTML, PDF, TXT) and HTML-ized manual pages to BIND 10 web server
  • upload generated API docs (doxygen and pydoc documentation) to the BIND 10 web server
  • email webmaster (web-request using the ticket) regarding website content and new releases; point to URL and provide announcement.
  • sign announcement
  • send signed announcement to bind10-announce, bf-announce, and bind-announce. (Also notify bind10-dev and bind10-users but not the official announcement)
  • blog entry about the release
  • update the internal release status wiki page.
  • update public wiki with new release URLs and version number.
  • tag the branch in git repository when finished editing.
  • update version in master's

(Note that this page doesn't mention all the specific scripts and commands jreed currently uses.)

Last modified 8 years ago Last modified on Oct 13, 2011, 1:03:37 PM