The one place for your designs
To upload designs, you'll need to enable LFS. More information
name: Release Checklist about: Create a new issue using this checklist for each release
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At the moment, Kea has only one supported release at a time, so the process tries to ensure that any modifications needed for a release take place on the master branch, rather than on a version-specific one. The basic steps for a release are:
Some of those checks and updates can be made before actual freeze, but it's reasonable to announce freeze now!
1. Check Jenkins results:
2. Is the distcheck passing on kea and kea+premium (https://jenkins.isc.org/job/kea-master-distcheck/)?
3. Check perflab if there is no critical errors there (https://perflab.isc.org/)
4. Make sure that there is no pending ticket to merge! (Use GitLab https://gitlab.isc.org/isc-projects/kea/merge_requests and https://gitlab.isc.org/isc-private/kea-premium/merge_requests or contact the development team).
5. Check the Known Issues list, is there something that suppose to be fixed before release and was omitted?
6. Check versioning:
7. Create Release Notes on Kea GitLab wiki using standard template, update all dates and versions. This wiki page should created under "release notes" folder, like this one: release-notes-1.5-final
8. Check if there is a Release Checklist ready. If not, create new one using this template (page could have been created, check Releases section at the bottom of this page)
The following steps may involve changing files in the repository. If any files will be updated, create a Kea ticket for them and make the changes on a separate branch.
2. Check !ChangeLog entries in Kea main and premium:
3. Check AUTHORS, INSTALL, README files in Kea main and premium.
4. Update information in sources about copyright dates, new version, etc. This is done manually using script https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
5. Regenerate parsers using docs.isc.org:
cd kea; autoreconf -fi; ./configure --with-log4cplus=/home/wlodek/log4cplus --enable-generate-parser (log4cplus in /home/wlodek should be available for everyone, if not - download your own) export PATH=/home/fdupont/bin:$PATH cd ~/kea/src/bin/dhcp4; touch *.yy; make parser cd ~/kea/src/bin/dhcp6; touch *.yy; make parser cd ~/kea/src/bin/d2; touch *.yy; make parser cd ~/kea/src/bin/agent; touch *.yy; make parser cd ~/kea/src/bin/netconf/; touch *.yy; make parser cd ~/kea/src/lib/eval; touch *.yy; make parser
TODO: we should regenerate all of them or just the one that been modified? 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.
That is the last moment to freeze code!
1. Update release version in configure.ac and remove -git suffix, and commit the change on master. From that moment all tarball builds can be officially released.
2. Go to tarball-internal Jenkins job and pick last tarball build - it will be a release candidate.
3. Tarball checks before requesting sanity checks from dev team
4. If all seems to be ok then upload tarballs to repo.isc.org