[Ffmpeg-devel] Re: 0.4.9-pre2?

Joshua Varner jlvarner
Wed Jun 29 22:04:53 CEST 2005


On 6/29/05, Jacob Meuser <jakemsr at jakemsr.com> wrote:
> On Wed, Jun 29, 2005 at 11:30:04AM +0200, Moritz Muehlenhoff wrote:
> > In gmane.comp.video.ffmpeg.devel, you wrote:
> > > no, not everyone.  you forget that most users use packages.  do you
> > > really think everyone who uses FFmpeg has the desire/ability to track
> > > FFmpeg cvs?
> >
> > E.g. Debian ships ffmpeg CVS snapshots instead of release tarballs.
> 
> yes, and even in OpenBSD, where I maintain the official port,
> I was granted an exception to use a CVS snapshot.  but then I
> have to check (compile and test) every port that uses FFmpeg,
> to make sure it works.  it would be a lot easier to just check
> and see what version of FFmpeg the developers of those projects
> know works, and use that version.
> 
> --
> <jakemsr at jakemsr.com>
> 
Since everyone is using CVS anyway, and until a more permanent release
system is developed why not provide tarballs for the use of package
maintainers. Just upload a new tarball every time the build number is
incremented (that's about monthly or so). It's not a release, no one
is claiming its a release its just a convenient snapshot that third
party packagers can work with more easily. It might be enough to quiet
the requests for releases a bit, if nothing else it would save
external packagers from the need to pick an arbitrary date to make a
snapshot.

It's not a perfect solution, but since every one is building off CVS
anyway, this would allow some semblance of stability. Given that the
build number is usually incremented at the same time as a major
commit, so there will be instability in the new features, that should
be ironed out by the next bump, so a simple policy of recommending the
tarball of the build following the debut of some feature could be
used.

This way ffmpeg can have "quasi-releases" that correspond to units of
functionality. The work of maintaining these "quasi-releases" would
fall on the third party packagers, but it would be simpler as they
could more easily share patches.

One of the strengths of ffmpeg is the rate of development and
improvement, so providing these tarballs could be a compromise between
those wanting stability and others wanting the cutting edge. They
would be provided with the caveat that they are not releases, but
merely recommendations, and bug fixes may require upgrading to the
next build.

Josh





More information about the ffmpeg-devel mailing list