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

[Ramiro Polla]

On Wed, Feb 10, 2010 at 12:52 PM, Reinhard Tartler <siretart at tauware.de> wrote:
> 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?

vlc.git$ grep -r LIBAVCODEC_VERSION_INT * | wc -l
38

> 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.

I don't think upgrade paths should have any effect on the issue here.
Uoti's example shows very well an use that may break.

Diego, how do you suggest we deal with version numbers in the releases?