Skip to content

Release Checklist

Jump to bottom
Wan-Teh Chang edited this page Jul 30, 2024 · 14 revisions

This is a helpful checklist on making a new libavif release.

Checklist

  • Come up with a new version number! For the purposes of this checklist, I'll use 6.7.7 as the old version, and 6.7.8 as the new one.
  • If this is a new release from a release branch, make sure all applicable critical patches from the main branch were cherry-picked into the release branch.
    The following command line lists the commits since the 6.7.7 release that are part of main but not yet on the 6.7.x branch, and which only impact files in the core library (src/*): 
    git log --oneline main ^v6.7.x --since $(git show -s --date=format:'%Y-%m-%d' --format=%cd $(git merge-base v6.7.7 v6.7.x)) -- src/*
  • Make sure each relevant change or fix has its own entry in the CHANGELOG.md file.
    To do so, click the CHANGELOG link. At the top of the page, there is an Unreleased link which is a shortcut to GitHub's list of every commit since the previous release. Use this to audit the current Unreleased CHANGELOG's list of Added/Changed/Removed and update it accordingly.
    Alternatively, the following command line lists the commits on the 6.7.x branch since the 6.7.7 release: 
    git log --oneline v6.7.x ^v6.7.7
  • Run the test suite (ctest) in Release, Debug (with assertions enabled) and sanitized builds. All tests must pass.
  • For a minor or patch release, check there is no incompatible API change: 
    git diff v6.7.7 -- include/avif/avif.h
  • For a minor or patch release, check there is no incompatible ABI change (abidiff is part of abigail-tools): 
    for TAG in v6.7.7 v6.7.x; do \
  git clone -b ${TAG} --depth 1 https://github.com/AOMediaCodec/libavif.git libavif_${TAG} && \
  cmake -S libavif_${TAG} -B libavif_${TAG}/build && \
  cmake --build libavif_${TAG}/build --parallel \
; done && \
abidiff libavif_v6.7.7/build/libavif.so libavif_v6.7.x/build/libavif.so
  • Update the CHANGELOG
    • Add a new header for the new version. It should look like ## [6.7.8] - 2021-09-22
    • Add/Update the links at the very bottom of the CHANGELOG. Unreleased should link to the new version ...HEAD, such as https://github.com/AOMediaCodec/libavif/compare/v6.7.8...HEAD, and you must add a new line that links your new version to the range since the last release, such as [6.7.8]: https://github.com/AOMediaCodec/libavif/compare/v6.7.7...v6.7.8.
  • Update CMakeLists.txt versions
    • Update the VERSION in the project() line near the top to the new version.
    • Bump the SOVERSION (LIBRARY_VERSION_*), following the documentation above it. SOVERSION's values are not intended to correspond with libavif's version, but simply be incremented correctly as library compatibility changes.
  • Update the version in avif.h
    • Set AVIF_VERSION_* values to correspond to your new version's values, and be sure to set AVIF_VERSION_DEVEL to 0.
  • Send a Pull Request with all these changes. Typically the commit message is the name of the new release, such as: git commit -a -m v6.7.8
  • Immediately update avif.h one more time, setting AVIF_VERSION_DEVEL back to 1. This can be done in another Pull Request.
    Alternatively this can be done as a second commit in the previous Pull Request, but "Rebase and merge" MUST be used instead of "Squash and merge".
  • Create and push a tag for this release: 
    git clone https://github.com/AOMediaCodec/libavif.git libavif_tag
cd libavif_tag
git tag v6.7.8 <v6.7.8 commit> -a -m v6.7.8
git push origin tag v6.7.8
  • Publish a new release on GitHub:
    • Choose a tag > v6.7.8
    • Release title: v6.7.8
    • Describe this release: Copy the relevant CHANGELOG block ("Added"/"Changed" sections)
    • Check the box "Set as the latest release" if this is the latest release
    • Check the box "Create a discussion for this release"
    • Click on "Publish release"
  • Some binary artifacts should be added by the CI to the release after some time. Make sure they exist and work.
  • Announce the new release, for example on the [email protected] and [email protected] mailing lists.

Examples

This section contains useful examples of what a release looks like.

Major release from the main branch

v1.0.0:

Minor release from the main branch

v1.1.0:

Patch release from a release branch

v1.0.3:

Clone this wiki locally