[FFmpeg-devel] [RFC] The Big Bump

Reinhard Tartler siretart
Fri Feb 4 21:52:09 CET 2011


On Fri, Feb 04, 2011 at 09:18:53 (CET), Stefano Sabatini wrote:

> On date Thursday 2011-02-03 21:06:31 +0100, Reinhard Tartler encoded:
>> On Thu, Feb 03, 2011 at 20:13:09 (CET), Diego Elio Petten? wrote:
>> 
>> > Il giorno gio, 03/02/2011 alle 16.35 +0100, Anton Khirnov ha scritto:
>> >> 
>> >> it's been suggested on IRC that we've accumulated enough new APIs and
>> >> the associated cruft so the time to bump major for lavf and lavc is
>> >> nigh. We should definitely do that before 0.7.
>> >
>> > I'd suggest doing this only if we can also ensure that no ff_* symbols
>> > are left as interlib dependencies.
>> 
>> This sounds pretty reasonable to me.
>> 
>> As already mentioned, this is an excellent occasion for revisiting
>> Stefanos error code concern in avutil and the (potential?) avcore/avutil
>> merge, which both obviously are better done before bumping.
>
> BTW what's the best timing for doing the changes?
>
> I believed that deep changes are better done just *after* release,

That's right, and nobody suggested deep changes. I expressed this on
IRC:

11:48 <siretart> elenril: TBH, I'd prefer to include the bump, because
                 not doing so will make backporting patches to the
                 release branch harder. AFAIUI the bump won't
                 destabilise the tree by itself

Having said this, stuff that breaks application of course should be
avoided so that we don't have to read stuff like this:

> indeed I can imagine that many users just upgrade for the release:
>
> - Hey, these guys finally released a new FFmpeg, let's try it!
>
> - Ouch, it breaks a lot of stuff, better to keep the ol' good FFmpeg,
>   I don't have time to fix it now.

Yeah, that would be pretty annoying. But as said, 'just' bumping major
and adding a few fields to structures *by itself* shouldn't destabilize
stuff.

> vs.
> - Well, they deprecated a lot of stuff and I'll have to cleanup later,
>   but it is already compiling *now*!

This is what has been done (successfully!) in the last two years.

> The same I can imagine go with distro packages, which are not usually
> very updated, so releasing and bumping later looks a better strategy,
> then depending projects have another year to upgrade to the new API
> and cleanup.

See above. I'm concerned about being able to backport fixes.



-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




More information about the ffmpeg-devel mailing list