10 KiB
10 KiB
Release Schedule
Code Freeze:
Tagging Deadline:
Public Release:
Documentation Review Links
Closed issues assigned to the milestone without a release note:
Merge requests merged into the milestone without a release note:
Merge requests merged into the milestone without a CHANGES entry:
Release Checklist
Before the Code Freeze
- (QA) Rebase -S editions on top of current open-source versions:
git checkout bind-9.18-sub && git rebase origin/bind-9.18 - (QA) Inform Support and Marketing of impending release (and give estimated release dates).
- (QA) Ensure there are no permanent test failures on any platform. Check public and private scheduled pipelines.
- (QA) Check charts from
shotgun:*jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol. - (QA) Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- (QA) Check whether all issues assigned to the release milestone are resolved1 .
- (QA) Ensure that there are no outstanding merge requests in the private repository1 (Subscription Edition only).
- (QA) Ensure all merge requests marked for backporting have been indeed backported.
- (QA) Announce (on Mattermost) that the code freeze is in effect.
Before the Tagging Deadline
- (QA) Inspect the current output of the
cross-version-config-testsjob to verify that no unexpected backward-incompatible change was introduced in the current release cycle. - (QA) Ensure release notes are correct, ask Support and Marketing to check them as well. Example
- (QA) Add a release marker to
CHANGES. Examples: 9.18, 9.16 - (QA) Add a release marker to
CHANGES.SE(Subscription Edition only). Example - (QA) Update BIND 9 version in
configure.ac(9.18+) orversion(9.16). - (QA) Rebuild
configureusing Autoconf ondocs.isc.org(9.16). - (QA) Update GitLab settings for all maintained branches to disallow merging to them: public, private
- (QA) Tag the releases in the private repository (
git tag -s -m "BIND 9.x.y" v9.x.y).
Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- (QA) Check that the formatting is correct for the HTML version of release notes.
- (QA) Check that the formatting of the generated man pages is correct.
- (QA) Verify GitLab CI results for the tags created and sign off on the releases to be published.
- (QA) Update GitLab settings for all maintained branches to allow merging to them again: public, private
- (QA) Prepare (using
version_bump.py) and merge MRs resetting the release notes and updating the version string for each maintained branch. - (QA) Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- (QA) Announce (on Mattermost) that the code freeze is over.
- (QA) Request signatures for the tarballs, providing their location and checksums. Ask signers on Mattermost.
- (Signers) Ensure that the contents of tarballs and tags are identical.
- (Signers) Validate tarball checksums, sign tarballs, and upload signatures.
- (QA) Verify tarball signatures and check tarball checksums again: Run
publish_bind.shon repo.isc.org to pre-publish. - (QA) Prepare the
patches/subdirectory for each security release (if applicable). - (QA) Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- (QA) Build and test ASN and/or Subscription Edition packages (in cloudsmith branch in private repo). Example
- (Marketing) Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).
On the Day of Public Release
- (QA) Wait for clearance from Security Officer to proceed with the public release (if applicable).
- (QA) Place tarballs in public location on FTP site.
- (QA) Inform Marketing of the release, providing FTP links for the published tarballs.
- (QA) Use the Printing Press project to prepare a release announcement email.
- (Marketing) Publish links to downloads on ISC website. Example
- (Marketing) Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- (Marketing) Update the Current Software Versions document in the SF portal if any stable versions were released.
- (Marketing) Send the release announcement email to the bind-announce mailing list (and to bind-users if a major release - example).
- (Marketing) Announce release on social media sites.
- (Marketing) Update Wikipedia entry for BIND.
- (Support) Add the new releases to the vulnerability matrix in the Knowledge Base.
- (Support) Update tickets in case of waiting support customers.
- (QA) Build and test any outstanding private packages in private repo. Example
- (QA) Build public RPMs. Example commit which triggers Copr builds automatically
- (SwEng) Build Debian/Ubuntu packages.
- (SwEng) Update Docker files here and make sure push is synchronized to GitHub. Docker Hub should pick it up automatically. Example
- (QA) Ensure all new tags are annotated and signed.
git show --show-signature v9.19.12 - (QA) Push tags for the published releases to the public repository.
- (QA) Using
merge_tag.py, merge published release tags back into the their relevant development/maintenance branches. - (QA) Ensure
allow_failure: trueis removed from thecross-version-config-testsjob if it was set during the current release cycle. - (QA) Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- (QA) Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate2 .
- (QA) Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant
Dockerfile. - (QA) Run a pipeline to rebuild all images used in GitLab CI.
- (QA) Update
metadata.jsonwith the upcoming release information.