Hi, while still travelling but having lurked from time to time on IRC, I note that some downstreams express some interest in libav 'snapshots'. In this context, I'd like to introduce and clarify a nomenclature which I think matches the workflow that Libav uses.
Releases: The Libav projects blesses deliverables in form of source code archives that are intended to be used by users and other downstream to use directly or have their application linked against them. Starting with 0.6.2, these releases are accompanied by binary archives for the win32 platform. Do we want and have the ressources to a) continue this and b) extend this to include .deb and .rpm packages? Upgrade Paths: In order to receive fixes and other improvements, newer releases supersede earlier releases. Not all upgrade combinations (i.e., an upgrade path) have similar characteristics regarding the risk of intended or unintended change in behavior. Release Series: Releases are supported for an yet undecided time frame. In order to minimize the risk for application developers and maintainers, we have so far introduced two release series '0.5' and '0.6', which both continue receive attention regarding, among others, security fixes. The upgrade paths /within/ a release series are considered 'safe', that is, the Libav project promises to avoid disruptive changes in order to minimize the risk of necessary changes in the application. This promise is explicitly not made for upgrade paths /across/ release series, for which the Libav developers reserve the right to introduce new and remove deprecated APIs. Beta Releases: are basically taken from master, with (almost) no modifications. The only addition is a VERSION file, which will read like '0.7b1' to indicate the first beta release. No branch in the official libav.org git is published; only the version that is used for creating the release tarballs is tagged. The upgrade path for beta releases are later releases (beta, rc or final releases) of the same series or other beta releases of the next later series. Release Candidates: At some point, the release managers decide to create a new release series by creating a new public and officially blessed branch in the 'main' git repository at libav.org. At this time, also a release candidate in form of a source archive is blessed and published. Official Releases: After creating the release branch, the testing period commences, during which distros and users are encouraged to extensively test and report experiences with the latest Release Candidate. Reported bug fixes always go to the 'master' branch first. The release managers cherry-pick revisions from the 'master' branch to the release branch in order to fix the reported regressions. I'd like to publish the text above on our website somewhere, so comments on the text itself and the location (e.g., the download page? new page?) are more than welcome. Having said this, I hereby nominate revision 14622ef0 as 0.7b1, i.e., the first beta release of the 0.7 release series. I have verified that this version compiles fine with latest mplayer svn. [1] After the tarball has been published (I currently lack write access to the release directory) and the revision is tagged, we can consider improving the version string produced by the script version.sh. A word on release frequencies: a number of downstreams have expressed an interest in more and faster releases. For this reason, I propose a frequency of ~8-12 weeks for beta releases and 2 new 'release series' a year, which I think is manageable given the current resources that we have. [1] https://launchpad.net/~motumedia/+archive/mplayer-daily/+buildjob/2479611 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
pgpKjDEPL8gHs.pgp
Description: PGP signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
