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.
Prerequisites
- 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..
Progression
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.
Activity
- 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.
Prerequisites
- 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/^/ - /'
Activity
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.bz2
- 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