[FFmpeg-devel] [RFC] The Big Bump
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
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
> - 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.
Reinhard Tartler, KeyID 945348A4
More information about the ffmpeg-devel