Skip to content

release 1.9.11

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.

  1. Check Jenkins results:
    1. Check Jenkins jobs for failures: distcheck, etc...
    2. Check Jenkins Tests Report.
    3. Check tarball check report
  2. Check Performance Test Results in Jenkins for drops in performance.
  3. 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 and q.w.e is the version previous to that)
  4. Prepare Release Notes
    1. 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
    2. Finish release notes and conduct its review
  5. 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.

  1. Run update-code-for-release.py
    Example command: GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/
    The script:
    • creates a Kea issue and MR for release changes,
    • runs several updating scripts
    • pushes the changes to MR
  2. Check manually User's Guide sections:
    1. Chapter 1. Introduction
      1. On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
      2. Did we add any additional 3rd party software? Update if needed
      3. Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
    2. Chapter 2. Quick Start
      1. Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
    3. Chapter 3. Installation
      1. Check installation hierarchy (this is also automatically checked at the end of ut-extended job)
      2. Check and update Build Requirements
      3. Check configure options against what ./configure -h says
  3. Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
  4. 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)
  5. 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! ❄

  1. Go to tarball-internal Jenkins job and pick the last tarball built - it will be a release candidate.
  2. Check tarball before requesting sanity checks from the development team.
    1. Download tarballs from picked Jenkins build
    2. Check sizes - is the new package reasonable?
    3. Check installation tree, compare it with the previous release
    4. Check installed lib versions
      1. which were updated? (save results)
      2. any of the lib from current release has lower number then corresponding lib from previous release? (!)
    5. Uninstall Kea, check what left (there should be just configuration files)
    6. Check if all of the installed binaries has man page
      1. if not, is it in the tarball?
      2. are man page up-to-date?
    7. Check if documentation is properly formatted, has correct versions and dates.
      1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
  3. Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
    1. Go to release-tarball-upload-internal Jenkins job.
    2. Click "Build with Parameters"
    3. In field "Tarball" select picked tarball build
    4. In field "Release_Candidate" pick:
      1. 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#
      2. 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)
      3. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
    5. Submit the job that will automatically:
      1. Upload the tarballs
        and if this is not the final version:
      2. Create a GitLab issue for sanity checks, put there the announcement
      3. Send Sanity Checks announcement via email to dhcp-team@isc.org and to 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

Releasing Tarballs and Packages

  1. Update Release Notes with ChangeLog entries
  2. Upload final RPM & DEB packages to cloudsmith.io
    1. Go to release-pkgs-upload-internal.
    2. Click "Build with Parameters" link
    3. Pick your selected pkg build in Packages field, and select PrivPubRepos: "both", TestProdRepos: "production" and click Build button.
    4. When it finishes run check: releases-pkgs-check-internal.
  3. Upload final tarballs to repo.isc.org
    1. Go to release-tarball-upload-internal Jenkins job.
    2. Click "Build with Parameters"
    3. In field "Tarball" select picked tarball build
    4. In field "Release_Candidate" pick final
      This job will also:
      • open an issue on the signing repository requesting signing final tarballs on repo.isc.org
      • create Git tags Kea-a.b.c in Kea main and premium repositories
      • send a signing request issue link on the DHCP Mattermost channel
  4. Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
  5. Mark Jenkins jobs with release artifacts to be kept forever:
    Go to the following Jenkins jobs, click release build and then, on the build page, click Keep this build forever button:
    1. tarball-internal job
    2. pkg job
  6. Update ReadTheDocs
    1. Trigger rebuilding docs on readthedocs.org.
    2. Publish currently released version. On the Versions tab, scroll down to Activate a version, search for kea-a.b.c and click Activate.
    3. 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 for 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 version a.b.c:
    • a.b.z-git where z == c + 1 or
    • a.y.0-git where y == b + 1 or
    • x.1.0-git where x == a + 1
Edited by Michael McNally
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information