Release Checklist

To assist with tracking work items in the closedown of a software release.

Item	Notes	Signed off
Release software version, as agreed with the community, is correct in the release branch in all necessary git repositories	Version metadata in the build needs to be correct.	<date>, <time>, <person>
Development software version has been incremented in the master development branch in all necessary git repositories	This is to ensure that future development builds do not identify as the released software.
All JIRA tickets that are marked as to be fixed in the release have been Closed.	Closed indicates that QA has signed off on the item as verified completed.
All JIRA tickets that are not Closed have been explicitly deferred from the Release.
All JIRA tickets that are Closed have been reviewed for documentation impact.
Release candidate build has been generated from the release branch	This is to ensure that future builds from the same branch are as close as possible to the original release build. Sometimes software reads the branch that is being built and includes it in within binaries within the build - eg. in "about this software" pages or metadata files.
Release candidate build has been produced with all binaries required	Installation image ISO, over-the-air upgrade package, netboot packages, open source software license spreadsheets.
Release candidate build has been identified with file size in bytes and a secure hash digest.	This information is a release deliverable. SHA-384 would currently be appropriate for the digest – check the latest NIST recommendations.
Release candidate build and other materials have been archived to a stable storage medium and backups successfully taken	To avoid loss of the release materials.
Release candidate build has successfully passed the build validation test threshold for a release build	This is to provide confidence that the release candidate build was correctly produced by the build machinery and contains the exact software that it is expected to.
Release candidate build has successfully passed the set of QA tests required of a release build	This is to ensure that the release candidate build has undergone sufficient testing to ensure that basic required functionality is working and has not been broken either by a late change to software or a build machinery failure.
QA test results for the release candidate build and builds produced in the run up to the release candidate build have been inspected and reviewed against the release critieria, and pass.	When considering test results obtained from builds prior to the RC, the set of changes to the software between the builds needs to be considered in order to determine whether the test results are valid for reasoning about the behaviour of the RC build.
No new ship-stopping defects have been identified in the last <agreed time period>.	This is an important, although not-necessarily-intuitive, item: use the detection of past serious defects as a predictor of future detection of serious defects.
Release notes document has been written with user-facing issues described	Must include all items that were agreed to when issues were deferred from the release.
Software documentation has been completed	Updated to reflect new features and changes to existing features.
Development report published	List all new features and improvements, all issues fixed in the release, and all issues explicitly deferred. This is a snapshot of JIRA information at the time of the release. More for project-internal stakeholders than consumers.
QA report published	Lists the test results used for evaluation of the release candidate build, including test cases executed against specific builds and the results. More for project-internal stakeholders than consumers.
Web and wiki pages describing releases have been updated with release candidate information	To be updated again post-release once a candidate build is promoted to release build.
Release candidate binaries have been inspected for Open Source software license compliance.	Note that the Open Source software license spreadsheets produced by the build are not exhaustive: in particular, information relating to the installer filesystem is not generated. Some Open Source licenses have impact on software documentation. The installer file system should be inspected to ensure that where necessary, copies of software licenses are present.