diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md new file mode 100644 index 0000000000..5ee3a6c01a --- /dev/null +++ b/.gitlab/issue_templates/Release.md @@ -0,0 +1,65 @@ +## Release Schedule + +**Tagging Deadline:** + +**ASN Deadline:** + +**Public Release:** + +## Release Checklist + +## 2 Working Days Before the Tagging Deadline + + - [ ] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1]. + - [ ] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only). + +## Before the Tagging Deadline + + - [ ] ***(QA)*** Inform Support/Marketing of impending release (and give estimated release dates). + - [ ] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released. + - [ ] ***(SwEng)*** Update API files for libraries with new version information. + - [ ] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only). + - [ ] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`. + - [ ] ***(SwEng)*** Update `CHANGES`. + - [ ] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only). + - [ ] ***(SwEng)*** Update `README.md`. + - [ ] ***(SwEng)*** Update `version`. + - [ ] ***(SwEng)*** Build documentation on `docs.isc.org`. + - [ ] ***(QA)*** Check that all the above steps were performed correctly. + - [ ] ***(QA)*** Check that the contents of release notes match the merge requests comprising the releases. + - [ ] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes. + - [ ] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.) + - [ ] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues. + +## Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases) + + - [ ] ***(QA)*** Run the `make release` Jenkins jobs to produce the tarballs and zips. + - [ ] ***(QA)*** Verify the results of `make release` Jenkins jobs and prepare a QA report for the releases to be published. + - [ ] ***(QA)*** Request signatures for the tarballs. + - [ ] ***(Signers)*** Sign the tarballs. + - [ ] ***(QA)*** Check tarball signatures. + - [ ] ***(QA)*** Notify Support that the releases are ready for publication. + - [ ] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built. + - [ ] ***(QA)*** Build and test ASN and/or Subscription Edition packages. + - [ ] ***(Support)*** Send out ASNs (if applicable). + +## On the Day of Public Release + + - [ ] ***(Support)*** Publish the releases according to the release schedule. + - [ ] ***(Support)*** Write release email to *bind9-announce*. + - [ ] ***(Support)*** Write email to *bind9-users* (if a major release). + - [ ] ***(Support)*** Update tickets in case of waiting support customers. + - [ ] ***(QA)*** Build and test any outstanding private packages. + - [ ] ***(QA)*** Build public packages (`*.deb`, RPMs). + - [ ] ***(QA)*** Inform Marketing of the release. + - [ ] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made. + - [ ] ***(Marketing)*** Post short note to Twitter. + - [ ] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND). + - [ ] ***(Marketing)*** Write blog article (if a major release). + - [ ] ***(QA)*** Ensure all new tags are annotated and signed. + - [ ] ***(SwEng)*** Push tags for the published releases to the public repository. + - [ ] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`). + +[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone. + +[^2]: Preferred command line: `git tag -u -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc. diff --git a/.gitlab/issue_templates/release.md b/.gitlab/issue_templates/release.md deleted file mode 100644 index dc6b80653b..0000000000 --- a/.gitlab/issue_templates/release.md +++ /dev/null @@ -1,44 +0,0 @@ -## Release Checklist - - - [ ] (Manager) Check for the presence of a milestone for the release: - - If there is a milestone, are all the issues for the milestone resolved? (other than this checklist). - - [ ] (Manager) Inform Support/Marketing of impending release (and give estimated release dates). - - (SwEng) Prepare the sources for tarball generation: - - [ ] Check perflab to ensure there has been no unexplained drop in performance for the version being released. - - [ ] Ensure that there are no outstanding merge requests in the private repository (subscription version only). - - [ ] Update API files for libraries with new version information. - - [ ] Change software version and library versions in configure.in (new major release only). - - [ ] Rebuild configure using autoconf on docs.isc.org. - - [ ] Update CHANGES. - - [ ] Update CHANGES.SE (subscription branch only). - - [ ] Update "version". - - [ ] Update "readme.md". - - Check the release notes are correct: - - [ ] Compare content with merge requests for the release. - - [ ] Check formatting. - - [ ] Build documentation on docs.isc.org. - - [ ] Commit changes and make sure the gitlab-ci tests are passing. - - [ ] Push the changes and tag ("alphatag" is an optional string such as "b1", "rc1" etc.). (```git tag -u -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]```) - - [ ] If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` (this allows development to continue on the release branch whilst release engineering continues). - - [ ] (SwEng) Run the "make release" Jenkins job to produce the tarballs and zips. - - [ ] (SwEng) Ask QA to sanity check the tarball and zips (passing to them the number of the Jenkins job). - - [ ] (QA) Sanity check the tarballs. - - [ ] (QA) Request the signature on the tarballs. - - [ ] (QA) Check signatures on tarballs. - - [ ] (QA) Tell Support to handle notification of release. - - [ ] (Manager) Inform Marketing of the release - - [ ] (Manager) Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made. - - [ ] (SwEng) Push tags for the published releases to the public repository. - - [ ] (SwEng) Update DEB and RPM packages. - - [ ] (SwEng) Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`). - -## Support - - [ ] Make tarballs and signatures available to download. - - [ ] Write release email to bind9-announce. - - [ ] Write email to bind9-users (if a major release). - - [ ] Update tickets in case of waiting support customers. - -## Marketing - - [ ] Post short note to Twitter. - - [ ] Update [Wikipedia entry for BIND](http://en.wikipedia.org/wiki/BIND). - - [ ] Write blog article (if a major release).