Release 1.9.5 checklist
name: Release Checklist
about: Create a new issue using this checklist for each release
Kea Release Checklist
This is thoroughly documented in the Kea Release Process guide.
Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
- Check Jenkins results:
-
Check Jenkins jobs for failures: distcheck, etc... -
Check Jenkins Tests Report. -
Check tarball check report
-
-
Check Performance Test Results in Jenkins for drops in performance. - Check versioning, ask the development team if:
- the library versions are being updated
-
KEA_HOOKS_VERSION
is being updated -
create an issue for that for developers in Gitlab - script: ./tools/bump-lib-versions.sh Kea-q.w.e Kea-a.b.c (where
a.b.c
is the version to be released andq.w.e
is the version previous to that)
- Prepare Release Notes
-
Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2 -
Finish release notes and conduct its review
-
-
Run release-pkgs-upload-internal and release-pkgs-check-internal to test repositories for correctness.
The following steps may involve changing files in the repository.
-
Create a Kea issue for code changes that will be made due to the following checks: - Check User's Guide sections:
- Chapter 1. Introduction
-
On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file. -
Did we add any additional 3rd party software? Update if needed -
Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
-
- Chapter 2. Quick Start
-
Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
-
- Chapter 3. Installation
-
Check installation hierarchy -
Check and update Build Requirements -
Check configure options against what ./configure -h
says
-
- Chapter 1. Introduction
-
Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc. -
Check AUTHORS, INSTALL, README files in Kea main and premium. - AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
-
Update information in sources about copyright dates, new version, etc, script: prepare_kea_release.sh. -
Regenerate parsers using docs.isc.org, script: regen-parsers.sh.
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
Build selection and upload package
This is the last moment to freeze code!
-
Go to tarball-internal Jenkins job and pick the last tarball built - it will be a release candidate. -
Check tarball before requesting sanity checks from the development team. - Download tarballs from picked Jenkins build
- Check sizes - is new package reasonable?
- Check the installation tree, compare it with the previous release
- Check installed lib versions
- which were updated? (save results)
- any of the lib from the current release has a lower number than the corresponding lib from the previous release? (!)
- Uninstall Kea, check what left (there should be just configuration files)
- Check if all of the installed binaries has man page
- if not, is it in the tarball?
- are man page up-to-date?
- Check if documentation is properly formatted, has correct versions and dates.
- it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
-
Upload tarballs to repo.isc.org using Jenkins - Go to release-tarball-upload-internal Jenkins job.
- Click "Build with Parameters"
- In field "Tarball" select picked tarball build
- In field "Release_Candidate" pick:
- rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
- next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
- final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
-
If none of the results force you to fix and rebuild the package, send sanity checks request if not already triggered automatically by release-tarball-upload-internal
.
Sanity Checks
-
Create Sanity Checks announcement, put there: - a link to chapter 4 Sanity Checks of the release process: KeaReleaseProcess - SanityChecks
- a link to an issue created in next step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
-
Create a GitLab issue for sanity checks, put there the announcement -
Send the announcement to dhcp-team@isc.org
Releasing Tarballs
-
Update Release Notes with ChangeLog entries -
Upload final tarballs to repo.isc.org - Go to release-tarball-upload-internal Jenkins job.
- Click "Build with Parameters"
- In field "Tarball" select picked tarball build
- In field "Release_Candidate" pick final
-
When the upload is completed then copy SHA checksums from the log and write an email to signers@isc.org requesting signatures of final tarballs on repo.isc.org indicating release directories. Attach SHA checksums to the request. -
Upload final RPM & DEB packages to cloudsmith.io - Go to release-pkgs-upload-internal.
- Click "Build with Parameters" link
- Pick your selected pkg build in Packages field, and select
PrivPubRepos: "both"
,TestProdRepos: "production"
and click Build button. - When it finishes run check: releases-pkgs-check-internal.
-
Create git tags Kea-a.b.c
in Kea main and premium repositories. - Update ReadTheDocs
-
Trigger rebuilding docs on readthedocs.org. -
Publish currently released version. On the Versions
tab, scroll down toActivate a version
, search forkea-a.b.c
and clickActivate
. -
For stable releases, change the default version to point to this stable release.
-
On the Day of Public Release
-
(Support) Wait for clearance from Security Officer to proceed with the public release (if applicable). -
(Support) Place tarballs in public location on FTP site. -
(Support) Publish links to downloads on ISC website. -
(Support) Write release email to kea-announce. -
(Support) Write email to kea-users (if a major release). -
(Support) Send eligible customers updated links to the Subscription software FTP site. -
(Support) If it is a new major version, sweng will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists. -
(Support) Update tickets in case of waiting support customers. -
(QA) Inform Marketing of the release. -
(Marketing) Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version. -
(Marketing) Announce on social media. -
(Marketing) Update Wikipedia entry for Kea. -
(Marketing) Write blog article (if a major release). -
(Marketing) Update Kea page on web site if any new hooks. -
(Marketing) Update Kea Premium and Kea Subscription data sheets if any new hooks. -
(Marketing) Update significant features matrix (if any significant new features). -
(Marketing) Update Kea documentation page in KB.
Post-Release, But Before Code Unfreeze
-
Bump up Kea version in configure.ac
to next development version which could be, based on just released versiona.b.c
:-
a.b.z-git
wherez == c + 1
or -
a.y.0-git
wherey == b + 1
or -
x.1.0-git
wherex == a + 1
-
-
Bump up REF_KEA_VERSION
inqa-dhcp/kea/jenkins/tarball-internal.jenkinsfile
tox.y.z
i.e. released version