[go: up one dir, main page]
Skip to content

Releasing

Jump to bottom Edit New page
Oneric edited this page Apr 21, 2024 · 11 revisions
  1. Wait for OSS-Fuzz, ART and Coverity Scan to check the latest master.
    • If the Coverity Scan daily quota is exceeded, wait until it resets and push to coverity_scan.
  2. Make sure the final releaser’s OpenPGP key is well-known:
    • It must be in the MAINTAINERS file. If not, have a previous release manager add it and sign the commit with their own key.
    • It must be on their GitHub account. This will ensure that GitHub shows the tag object as “verified”.
    • It should be on other well-known key servers.
  3. Make the release commit locally, using “Release version” as the commit subject:
    • Update the public version number in RELEASEVERSION.
    • Update LIBASS_VERSION (which directly corresponds to the public version number) in libass/ass.h.
    • Update the libtool version number in libass/Makefile.am.
      • If old program binaries don’t work with the new library, increment current and reset revision and age to 0.
      • If old program binaries work with the new library but new program binaries may not work with the old library, increment current and age and reset revision to 0.
      • Otherwise, just increment revision.
      • Another way to see this is to imagine an ABI-centric semantic version number computed as $(current − age) . age . revision.
      • Ideally, all significant ABI changes (which affect current and age) should update the libtool version number in the same commit that enacts the ABI change itself, and releases should only ever increment revision. However, this is sometimes forgotten, so do verify this when preparing a release.
    • Update the changelog in, well, Changelog.
    • Update the version number, release date and change summary in README.md.
    • Put any extra release notes in the commit message.
  4. Run ./autogen.sh && ./configure && make distcheck. Make sure it reports no errors.
  5. Compare the generated libass-version.tar.gz to the previous release tarball to ensure everything is included.
  6. Do a compile test with the sources extracted from the tarball.
  7. Run make dist-xz (or manually recompress the tar.gz) to create libass-version.tar.xz.
  8. Tag the release commit with the new public version number using a signed tag object (git tag -s):
    • Use “libass version” as the tag object’s subject line.
    • Use the release notes from the commit message body and the text added to Changelog as the description.
  9. Sign the tarballs using the same key to create .asc signature files: gpg -ab libass-version.tar.gz && gpg -ab libass-version.tar.xz
  10. Push the release commit and the tag to GitHub.
  11. Make a release on GitHub (a draft can be started ahead of time):
    • Use “Release version” as the title.
    • Reuse the tag object’s description, tweaked for better Markdown if necessary.
    • Upload the two tarballs and the two tarball signatures as “binaries”.
  12. Find the newest commit in libass-tests for which the new release passes with ART_REG_TOLERANCE=0 (on platforms using canonical floating-point precision at least). Tag this commit as compatible_<release version> and push it.
Add a custom footer

Informational Pages

libass development

ASSv5 (stale)

Clone this wiki locally