[libav-devel] [PATCH] Bump major version for b8e893399ff8755721dc117695ec5ff183c1e07b

[Måns Rullgård]

Reinhard Tartler <siretart at tauware.de> writes:

> On Mon, Jun 20, 2011 at 12:47:55 (CEST), Kostya wrote:
>
>> On Mon, Jun 20, 2011 at 11:42:34AM +0100, Måns Rullgård wrote:
>>> Kostya <kostya.shishkov at gmail.com> writes:
>>> 
>>> > On Mon, Jun 20, 2011 at 11:36:34AM +0100, Måns Rullgård wrote:
>>> >> Kostya <kostya.shishkov at gmail.com> writes:
>>> >> 
>>> >> > On Mon, Jun 20, 2011 at 12:21:43PM +0200, Reinhard Tartler wrote:
>>> >> >> That change broke ABI, so we need to recompile all applications
>>> >> >> ---
>>> >> >>  libswscale/swscale.h |    4 ++--
>>> >> >>  1 files changed, 2 insertions(+), 2 deletions(-)
>>> >> >> 
>>> >> >> diff --git a/libswscale/swscale.h b/libswscale/swscale.h
>>> >> >> index b0ad912..24b447d 100644
>>> >> >> --- a/libswscale/swscale.h
>>> >> >> +++ b/libswscale/swscale.h
>>> >> >> @@ -29,8 +29,8 @@
>>> >> >>  
>>> >> >>  #include "libavutil/avutil.h"
>>> >> >>  
>>> >> >> -#define LIBSWSCALE_VERSION_MAJOR 1
>>> >> >> -#define LIBSWSCALE_VERSION_MINOR 1
>>> >> >> +#define LIBSWSCALE_VERSION_MAJOR 2
>>> >> >> +#define LIBSWSCALE_VERSION_MINOR 0
>>> >> >>  #define LIBSWSCALE_VERSION_MICRO 0
>>> >> >>  
>>> >> >>  #define LIBSWSCALE_VERSION_INT  AV_VERSION_INT(LIBSWSCALE_VERSION_MAJOR, \
>>> >> >> -- 
>>> >> >
>>> >> > Why major version? IMO minor version bump is enough.
>>> >> 
>>> >> A few external interfaces changed from long to int, which is a major break.
>>> >
>>> > For some reason we don't have rules for ABI change, except for this abstract
>>> > in developer.texi:
>>> >
>>> >     Incrementing the second component means backward compatible change
>>> >     (e.g. addition of a function to the public API or extension of an
>>> >     existing data structure).
>>> >
>>> > Just my can of paint...
>>> 
>>> This change isn't binary compatible on all systems.
>>
>> Obviously, but should we define that in rules or not? Originally nobody cared
>> about binary form distribution at all.
>
> We do care about binary form distribution since the 0.5 release. If we
> didn't we could as well leave release alone completely.
>
> Ronald elaborated on irc a bit more. The thing is that on architectures
> such as x86 (both 32 bit and 64bit), the stack element size is fixed,

Does x86_64 use 8-byte stack slots even for 32-bit parameters?

> which maintains alignment. This means that here, all is just
> fine. However, as I understand Måns, we do support also other
> architectures, where this property is not maintained and therefore,
> applications will crash horribly.

I don't remember the details of every ABI, and it's possible none of
them are in fact affected by this particular change.  Many of those with
different-size int and long pass those arguments in a register where it
wouldn't matter.

That said, I'd rather not take any chances.

-- 
Måns Rullgård
mans at mansr.com