2.5.2 release checklist
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.
For new stable releases or maintenance releases, please don't use kea-dev
build farm. Use dedicated build farm for each release cycle.
- 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)
-
Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already. - If any changes have been done to database schemas, then:
-
Check that a previously released schema has not been changed. -
Check that the additions to dhcpdb_create.*sql
, and nothing more nor less than what was added in this release, is present in aupgrade_*_to_*.sh.in
script that should also have been added in this release.
-
- 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-2.1.0 -
Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
-
-
Check that packges can be uploaded to cloudsmith. - Go to release-upload-to-cloudsmith.
- Click
Build with Parameters
. - Pick the latest pkg build in the
Packages
field, and the corresponding tarball build in theTarball
field, leave the rest as they arePrivPubRepos: "private"
,TarballOrPkg: "packages"
,TestProdRepos: "testing"
and clickBuild
. - If a new Cloudsmith repository is used, then:
-
Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository. -
Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the check-pkgs.py QA tool.
-
-
Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working. - Trigger rebuilding docs on readthedocs.org and wait for the build to complete.
The following steps may involve changing files in the repository.
-
Run update-code-for-release.py
Example command:GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 --repo-dir ~/isc/repos/kea/
Use--upload
to commit changes.
Help:GITLAB_TOKEN="..." ./update-code-for-release.py --help
This script makes the following changes and actions:- run prepare_kea_release.sh that does:
- add release entries in ChangeLogs
- update Kea version in configure.ac
- update copyright years in files that were changed in current year
- sort message files
- regenerate message files headers
- regenerate parsers using Bison from Docker
With--upload
: - create an issue in GitLab for release changes in kea repo
- create branches and merge requests for kea and kea-premium
- commit the changes in both repos
- checkout created branches in both repos
- commit and push the changes to GitLab server
- run prepare_kea_release.sh that does:
- Check manually 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 (this is also automatically checked at the end of ut-extended job) -
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)
-
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 MR to master.
Build selection, tarballs upload and sanity checks
This is the last moment to freeze code!
-
Go to build-tarball 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 hook libraries.
- Are there any new hook libraries installed in this release?
- Are they in the proper tarball? Premium or subscription?
- Do they have their own package?
- Are there any new hook libraries installed in this release?
- Check sizes - is the new package reasonable?
- Check installation tree, compare it with the previous release
- Check installed libraries.
- which were updated? (save results)
- Do any of the libraries from the current release have lower version than in the previous release?
- Uninstall Kea, check what left (there should be just configuration files)
- Check if each of the installed binaries has a man page.
- If not, is the binary included in the tarball? That might explain it.
- Are man pages 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 and send sanity checks request. - Go to release-tarball-upload Jenkins job.
- Click
Build with Parameters
. - In field
Tarball
select picked tarball build. - In field
Pkg
select the corresponding pkg job. - In field
Release_Candidate
pick:-
rc1
if this is the first selected build for release, it will push the 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 an error)
-
- Submit the job that will automatically:
- Upload the tarballs
and if this is not the final version: - Create a GitLab issue for sanity checks, put there the announcement
- Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.
The announcement includes:- a link to chapter 4 Sanity Checks of the release process: KeaReleaseProcess - SanityChecks
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
- Upload the tarballs
Releasing Tarballs and Packages
-
Update Release Notes with ChangeLog entries -
Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2):
Go to the following Jenkins jobs, click release build and then, on the build page, clickKeep this build forever
button and edit description:
-
Upload final tarballs to repo.isc.org. - Go to release-tarball-upload Jenkins job.
- Click
Build with Parameters
. - In field
Tarball
select picked tarball build. - In field
Pkg
select the corresponding pkg job. - In field
Release_Candidate
pickfinal
.
This job will also:- open an issue on the signing repository for signing final tarballs on repo.isc.org
- create Git tags
Kea-a.b.c
in Kea main and premium repositories - if release engineer is holding personal signing key, please use sign, verify, and upload script
- if release enginner do NOT have signing key, please contact team member.
-
Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io - Go to release-upload-to-cloudsmith.
- Click
Build with Parameters
. - Pick your selected pkg build in the
Packages
field, the corresponding tarball build in theTarball
field,PrivPubRepos: "both"
,TarballOrPkg: "both"
,TestProdRepos: "production"
and clickBuild
.- This step also verifies sign files.
- When it finishes run check: releases-pkgs-check.
-
Update ReadTheDocs - Trick ReadTheDocs into pulling the latest tags. Click
Build version
on readthedocs.org. - Publish currently released version. On the
Versions
tab, scroll down toActivate a version
, search forkea-a.b.c
and clickActivate
. - If it's a stable release, change the default version to point to this stable release.
Admin -> Advanced Settings -> Default version* -> Kea-a.b.c
.
- Trick ReadTheDocs into pulling the latest tags. Click
-
Create an issue and a merge request to 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
most of the time, or -
a.y.0-git
wherey == b + 2
if a new development series starts, or -
x.1.0-git
wherex == a + 1
when the released minor versionb
is 9 anda.b.c
was the last version in the development series and a new development version is coming up next.
-
-
Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
On the Day of Public Release
-
(Support) Wait for clearance from Security Officer to proceed with the public release (if applicable). -
(Support) Confirm that the tarballs have the checksums mentioned on the signing ticket. -
(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.minor
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 for support customers. -
(Support) Inform Marketing of the release. -
(Marketing) If a new Cloudsmith repository is used, update the Zapier scripts. -
(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 website 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).