[FFmpeg-cvslog] r21731 - in branches/0.5: . Changelog doc/APIchanges libavcodec/avcodec.h libavcodec/utils.c

[Reinhard Tartler]

On Mi, Feb 10, 2010 at 12:54:36 (CET), Uoti Urpala wrote:

> On Wed, 2010-02-10 at 11:00 +0100, Reinhard Tartler wrote:
>> On Di, Feb 09, 2010 at 22:28:09 (CET), Ramiro Polla wrote:
>> > -#define LIBAVCODEC_VERSION_MINOR 20
>> > +#define LIBAVCODEC_VERSION_MINOR 21
>
>> > This is bad.
>> 
>> why?
>> 
>> > We have the same version bump for 2 different things. How should we
>> > deal with library versions in the branches?
>> 
>> We don't. Let me explain:
>> 
>> since nothing in the ffmepg source checks for LIBAVCODEC_VERSION_MINOR,
>> this has can have only effect on other applications that link
>> dynamically against avcodec.
>
> You need to consider more than binary compatibility. The minor version
> bumps typically add new public functions or definitions; the original
> minor 21 added av_parser_parse2 for example. A user application that
> wants to support older libavcodec versions could have code like this:
>
> #if LIBAVCODEC_VERSION_MINOR >= 21
> av_parser_parse2(...)
> #else
> ...
> #endif
>
> Compiling this application against the release branch would fail now, as
> it'd try to use a function not present in the old release code.

Do you have one or more specific examples of applications that check the
LIBAVCODEC_VERSION_MINOR setting?

As indicated in my previous post, when considering the relevant upgrade
paths, I don't think this is currenly a problem.

I agree that changes like this could open pandora's box if used
carelessly, though.

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