[Ffmpeg-devel] Re: 0.4.9-pre2?

Jacob Meuser jakemsr
Wed Jun 29 22:14:18 CEST 2005

On Wed, Jun 29, 2005 at 03:04:53PM -0500, Joshua Varner wrote:
> 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.

that would suit my needs perfectly fine, as long as those tarballs
were also kept available for download for some time (at least a few

I would also like to see real shared library version number management
in FFmpeg, but that is another discussion, and given that many here
are against shared libraries, I wouldn't expect the discussion to get
very far before turning into a flamefest.

<jakemsr at jakemsr.com>

More information about the ffmpeg-devel mailing list