[Ffmpeg-devel] Creating releases
Sat Apr 14 14:48:15 CEST 2007
Axel Thimm <Axel.Thimm at ATrpms.net> writes:
> I know that ffmpeg prefers users to run the latest snapshots. But that
> doesn't work so well for 3rd party projects (e.g. ffmpeg consumers)
> and also not for packagers of various distributions.
> I'm packaging ffmpeg for various Red Hat/Fedora distros and am talking
> with several other packagers for the same distros on how to get our
> bits together. Turns out that everyone has a different snapshot where
> different features/bugs exist. Some have backported selected svn
> fixes, or have patched up the sources themselves. I think (frequent)
> releases would help out a lot.
> I would volunteer to help creating formal releases, so that the ffmpeg
> development doesn't get slowed down by additional workload. Probably
> most of the release process could be automated enough to have often
> enough releases to track the fast development pace of ffmpeg.
> The choice when to cut a release would have to come from the
> development team/head, though.
> What do you think?
Many projects use an iterative development model where the code is
chopped into tiny, tiny pieces, and then weeks/months/years are spent
piecing them back together to form a "release", after which the
process is repeated again. In these projects, snapshots between
releases are very unstable, and often do not even compile.
FFmpeg does not follow this model. Our aim is that head of svn should
always be stable, and to a large extent this is true. Serious bugs
usually get fixed rather quickly. Less serious bugs are equally
likely to be present in any revision.
The problem with releases is that users will tend to use (at best) the
latest release version, and will report bugs against this. Many of
these bugs will have been already fixed, and thus investigating these
reports is largely a waste of developer time.
If you wish to make releases, nobody will stop you. However, we would
ask of you to very clearly request bug reports to be sent to you, and
that you check the reports against the development head, forwarding
any bugs that are still unfixed to us. Of course you would also
filter out duplicates.
As for when to release, each revision is, as far we know, as good as
another. There are no known-stable revisions if that is what you are
To summarize, you are free to make whatever releases you wish, but you
will be on your own.
mans at mansr.com
More information about the ffmpeg-devel