Merge commit '23f4c5acc438366d84cacf49e33b0bcd72f04937'
authorMichael Niedermayer <michaelni@gmx.at>
Sun, 17 Mar 2013 11:32:07 +0000 (12:32 +0100)
committerMichael Niedermayer <michaelni@gmx.at>
Sun, 17 Mar 2013 11:58:44 +0000 (12:58 +0100)
* commit '23f4c5acc438366d84cacf49e33b0bcd72f04937':
  document the release process

Merged-by: Michael Niedermayer <michaelni@gmx.at>
1  2 
doc/developer.texi

@@@ -543,38 -529,125 +543,123 @@@ After a patch is approved it will be co
  We will review all submitted patches, but sometimes we are quite busy so
  especially for large patches this can take several weeks.
  
 -When resubmitting patches, if their size grew or during the review different
 -issues arisen please split the patch so each issue has a specific patch.
 +If you feel that the review process is too slow and you are willing to try to
 +take over maintainership of the area of code you change then just clone
 +git master and maintain the area of code there. We will merge each area from
 +where its best maintained.
 +
 +When resubmitting patches, please do not make any significant changes
 +not related to the comments received during review. Such patches will
 +be rejected. Instead, submit significant changes or new features as
 +separate patches.
 +
 +@anchor{Regression tests}
 +@section Regression tests
  
 -@anchor{Regression Tests}
 -@section Regression Tests
 +Before submitting a patch (or committing to the repository), you should at least
 +test that you did not break anything.
  
 -Before submitting a patch (or committing to the repository), you should at
 -least make sure that it does not break anything.
 +Running 'make fate' accomplishes this, please see @url{fate.html} for details.
  
 -If the code changed has already a test present in FATE you should run it,
 -otherwise it is advised to add it.
 +[Of course, some patches may change the results of the regression tests. In
 +this case, the reference results of the regression tests shall be modified
 +accordingly].
  
 -Improvements to codec or demuxer might change the FATE results. Make sure
 -to commit the update reference with the change and to explain in the comment
 -why the expected result changed.
 +@subsection Adding files to the fate-suite dataset
 +
 +When there is no muxer or encoder available to generate test media for a
 +specific test then the media has to be inlcuded in the fate-suite.
 +First please make sure that the sample file is as small as possible to test the
 +respective decoder or demuxer sufficiently. Large files increase network
 +bandwidth and disk space requirements.
 +Once you have a working fate test and fate sample, provide in the commit
 +message or introductionary message for the patch series that you post to
 +the ffmpeg-devel mailing list, a direct link to download the sample media.
  
 -Please refer to @url{fate.html}.
  
 -Libav maintains a set of @strong{release branches}, which are the
+ @anchor{Release process}
+ @section Release process
 -Linux distributions, etc.). At irregular times, a @strong{release
++FFmpeg maintains a set of @strong{release branches}, which are the
+ recommended deliverable for system integrators and distributors (such as
 -@url{http://libav.org} website.
++Linux distributions, etc.). At regular times, a @strong{release
+ manager} prepares, tests and publishes tarballs on the
 -Note that we promise to our users that shared libraries from any Libav
++@url{http://ffmpeg.org} website.
+ There are two kinds of releases:
+ @enumerate
+ @item
+     @strong{Major releases} always include the latest and greatest
+     features and functionality.
+ @item
+     @strong{Point releases} are cut from @strong{release} branches,
+     which are named @code{release/X}, with @code{X} being the release
+     version number.
+ @end enumerate
 -on the @strong{libav-devel} mailing list in time to allow forward planning.
++Note that we promise to our users that shared libraries from any FFmpeg
+ release never break programs that have been @strong{compiled} against
+ previous versions of @strong{the same release series} in any case!
+ However, from time to time, we do make API changes that require adaptations
+ in applications. Such changes are only allowed in (new) major releases and
+ require further steps such as bumping library version numbers and/or
+ adjustments to the symbol versioning file. Please discuss such changes
 -    Fixes a documented bug in @url{http://bugzilla.libav.org}.
++on the @strong{ffmpeg-devel} mailing list in time to allow forward planning.
+ @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 a @strong{CVE
+     number} issued by @url{http://cve.mitre.org/}.
+ @item
 -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.
 -
++    Fixes a documented bug in @url{https://ffmpeg.org/trac/ffmpeg}.
+ @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.
 -    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.
+ @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
 -    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
++    Add the release at @url{https://ffmpeg.org/trac/ffmpeg/admin/ticket/versions}.
+ @item
+     Announce the intent to do a release to the mailing list.
+ @item
 -    Prepare the release tarballs in @code{xz} and @code{gz} formats, and
 -    supplementing files that contain @code{md5} and @code{sha1}
 -    checksums.
+     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
 -    Publish the tarballs at @url{http://libav.org/releases}. Create and
 -    push an annotated tag in the form @code{vX}, with @code{X}
++    Prepare the release tarballs in @code{bz2} and @code{gz} formats, and
++    supplementing files that contain @code{gpg} signatures
+ @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
++    Publish the tarballs at @url{http://ffmpeg.org/releases}. Create and
++    push an annotated tag in the form @code{nX}, with @code{X}
+     containing the version number.
+ @item
++    Propose and send a patch to the @strong{ffmpeg-devel} mailing list
+     with a news entry for the website.
+ @item
+     Publish the news entry.
+ @item
+     Send announcement to the mailing list.
+ @end enumerate
  @bye