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

[Uoti Urpala]

On Tue, 2011-02-22 at 17:56 +0100, Reinhard Tartler wrote:
> On Tue, Feb 22, 2011 at 16:39:53 (CET), Uoti Urpala wrote:
> > 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

> As we expect distros to use releases, we cannot really talk in 'months'
> but only about FFmpeg releases. I think one release should be enough to

I mean dropping them in git master, which can obviously happen at any
point (and is relevant to many users). And it matters for the timeline
because of point 4; likely at least some users or developers of an
application would use an FFmpeg version newer than the last released
one.

Of course the deprecated API could be kept until the next major bump
too; but if the situation is "we don't want to keep all this crap until
the next major bump", then removing things that were already officially
deprecated at the bump later without doing another version bump is a
lesser evil than removing them at the bump and having no compatibility
for the transition period (particularly API-only removals).


> adapt. Moreover, I'm open to discuss how often we want to release. For
> instance, I understand from gstreamer that they would rather prefer two
> releases a year over one.
> 
> Regarding how much time it takes to do such a transition properly,
> please have a look at this to get an impression what work is involved
> here: http://release.debian.org/transitions/ffmpeg.html

I don't see how that would be relevant. Nothing discussed here would set
a deadline on how quickly distros would have to get rid of all package
versions using the pre-bump library packages. The only expectation is
that distros have the new library version available within a month of
release. If you are able to _start_ a transition like the above then
you've already completed that step.