[FFmpeg-devel] [RFC] The Big Bump checklist

[Uoti Urpala]

On Tue, 2011-02-22 at 14:58 +0100, Diego Elio Petten? wrote:
> Il giorno mar, 22/02/2011 alle 14.41 +0100, Stefano Sabatini ha scritto:
> > Releasing and dropping the deprecated API just afterhand, and give
> > another year for application developers to catch up with the new API
> > seems a much better plan to me, especially considering how disruptive
> > the bump will be given the delay from the previous one. 
> 
> Wait, I'm talking about bumping ABI, not API. You can keep the old API
> as deprecated by using inline wrappers, but mapping to the new ABI.
> 
> This way you still have source compatibility between the old and new
> FFmpeg, but also a binary compatibility between 0.7 and git master. And
> you drop the huge overhead currently present in the FFmpeg libraries on
> shared linking.

IMO this is what should be done, but at the moment various features are
scheduled to be dropped at the next major version bump. For some of the
scheduled drops (SampleFormat for example) the new API has only been
added recently. I think that should be changed and the deprecated API
should be kept for some time after the bump.

I mean a timeline something like this:
     1. major bump in FFmpeg followed by release; old API kept where
        possible
     2. distros begin switching, but there will be a transition period
        where both versions are in use; applications can keep using old
        API to compile against either version without too many
        complications
     3. after giving distros a month or two to make the new FFmpeg
        available the deprecated APIs are dropped
     4. all applications switch to using the new API only, dropping
        compatibility with pre-bump FFmpeg versions