Differences between revisions 12 and 13
Revision 12 as of 2016-02-07 22:16:43
Size: 3621
Editor: SeanMcGovern
Comment: Add a command line to generate a preliminary Changelog list
Revision 13 as of 2017-10-14 01:00:25
Size: 3620
Editor: DonDiego
Comment: .bz2 --> .xz
Deletions are marked like this. Additions are marked like this.
Line 61: Line 61:
 * gpg sign them with ``gpg -ab libav-*.tar.gz``, ``gpg -ab libav-*.tar.bz2``  * gpg sign them with ``gpg -ab libav-*.tar.gz``, ``gpg -ab libav-*.tar.xz``

Libav Release Checklist

Major Releases

Major releases contain the result of a whole development cycle, new features get introduced, old code gets removed and incompatible changes may happen.

Ideally it should happen at least once per season.

Even major release may break API compatibility with a previous release, Odd releases must retain backwards compatibility with the previous code. That means that incompatible ABI changes could happen every release, but moving from Even to Odd would just require a rebuild of the software using the new headers and libraries.

  • Longer delays in breaking compatibility could happen, but should not be taken for granted.


  • Make sure there are no known regression left to be fixed
  • Prepare the ReleaseNotes

  • Make sure APIchanges entries point to the right commit.
  • Make sure that the Migration guide is up to date and prepare additional PortingHowTo pages for deprecated features requiring radical changes..


  • alpha releases are tagged from the master immediately after the major version is bumped and the new feature and deprecation guards are updated accordingly, this enables code previously disabled by default and removes the code marked for deprecation. Small features could still appear while in alpha phase, no API nor ABI changes can happen.

  • beta the first beta is tagged as the codebase is branched, no additional features can be added from this moment.

  • releases/pre-releases they are tagged from the release branch, code for the release branch is backported from the master when possible and must be only bugfixes.


  • Create a snapshot of the fate-suite samples and change the release branch to use it
  • Push the ReleaseNotes along a ReleaseTag pointing to it

  • Open a new ReleaseBranch

  • Use the continuous integration task to roll the tarballs and the windows build.
  • Update the website news and download sections.

Point Releases

Point releases contain only bugfixes. No behavioural changes are to be expected and applications leveraging Libav should not require changes to keep working.

Point releases live within a ReleaseBranch, all the changes are backported from the MasterBranch, they can happen monthly on average.


  • Make sure there are no regressions are introduced
  • Prepare the ReleaseNotes:

    • Copy the short description from git patches to entries in Changelog, make sure to copy references to Bugtrackers (both libav, or distro trackers) / CVE references, etc. to each entry. A quick way to generate it from the command line would be:

git log --oneline <previous release tag>.. | tail -r | cut -d ' ' -f 2- | sed 's/^/ - /'


  • Push the ReleaseNotes along a ReleaseTag pointing to it

  • Use the continuous integration task to roll the tarballs and the windows build.
  • Update the website news and download sections.

How to roll tarballs

  • Use the appropriate Job on jenkins, download the archived artifacts

  • gpg sign them with gpg -ab libav-*.tar.gz, gpg -ab libav-*.tar.xz

  • Until we teach Jenkins how to create/push the tag, use this command:

git tag -a -m"$(cat RELEASE) release" "v$(cat RELEASE)"

and install the tarballs manually to http://libav.org/releases