---
doc/developer.texi | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index 54c1ec6..af3e9e6 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -547,4 +547,102 @@ why the expected result changed.
Please refer to @url{fate.html}.
+@anchor{Release process}
+@section Release process
+
+Libav maintains a set of @strong{release branches}, which are the
+recommended deliverable for system integrators and distributors (such as
+Linux distributions, etc.). At irregular times, a @strong{release
+manager} prepares, tests and publishes tarballs on the
+@url{http://libav.org} website.
+
+There are two kinds of releases:
+
+@enumerate
+@item
+ @strong{Major releases} are cut from the @strong{Libav}
+ @code{master} branch. They always include the latest and greatest
+ features and functionality. However, the resulting shared libraries
+ must not break programs that have been @strong{compiled} against
+ previous versions of @strong{Libav} in any case! (NB: changes that
+ require adaptations to applications need to be discussed on the
+ @strong{libav-devel} mailing list and usually involve a buming the
+ major version of the library).
+@item
+ @strong{Point releases} are cut from @strong{release} branches. They
+ are named @code{release/X}, with @code{X} being the release version
+ number. See @ref{Criteria for Point Releases} for details.
+@end enumerate
+
+
+@anchor{Criteria for Point Releases}
+@subsection Criteria for Point Releases
+
+Changes that match the following criteria are valid candidates for
+inclusion into a point release:
+
+@enumerate
+@item
+ Fixes a security issue, preferably identified by an @strong{CVE
+ number} issued by @url{http://cve.mitre.org/}.
+@item
+ Fixes a documented bug in @url{http://bugzilla.libav.org}.
+@item
+ Improves the included documentation.
+@item
+ Retains both source-code and binary compatibility with previous
+ point releases of the same release branch.
+@end enumerate
+
+The order for checking the rules is (1 OR 2 OR 3) AND 4.
+
+All Libav developers are welcome to nominate commits that they push to
+@code{master} by mailing the @strong{libav-stable} mailing list. The
+easiest way to do so is to include @code{CC: libav-stable@@libav.org} in
+the commit message.
+
+
+@subsection Release Checklist
+
+The release process involves the following steps:
+
+@enumerate
+@item
+ Ensure that the @file{RELEASE} file contains the version number for
+ the upcoming release.
+@item
+ File a release tracking bug in @url{http://bugzilla.libav.org}. Make
+ sure that the bug has an alias named @code{ReleaseX.Y} for the
+ @code{X.Y} release.
+@item
+ Announce the intent to do a release to the mailing list.
+@item
+ Reassign unresolved blocking bugs from previous release
+ tracking bugs to the new bug.
+@item
+ Review patch nominations that reach the @strong{libav-stable}
+ mailing list, and push patches that fulfill the stable release
+ criteria to the release branch.
+@item
+ Ensure that the FATE regression suite still passes in the release
+ branch on at least @strong{i386} and @strong{amd64}
+ (cf. @ref{Regression Tests}).
+@item
+ Prepare the release tarballs in @code{xz} and @code{gz} formats, and
+ supplementing files that containing @code{md5} and @code{sha1}
+ checksums.
+@item
+ Publish the tarballs at @url{http://libav.org/releases}. Create and
+ push an annotated tag in the form @code{vX}, with @code{X}
+ containing the version number.
+@item
+ Build the tarballs with the Windows binaries, and publish them at
+ @url{http://win32.libav.org/releases}.
+@item
+ Propose and send a patch to the @strong{libav-devel} mailing list
+ with a news entry for the website.
+@item
+ Publish the news entry.
+@end enumerate
+
@bye
--
1.7.9.5
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
