Kostya <[email protected]> writes: > On Mon, Jun 20, 2011 at 11:42:34AM +0100, Måns Rullgård wrote: >> Kostya <[email protected]> writes: >> >> > On Mon, Jun 20, 2011 at 11:36:34AM +0100, Måns Rullgård wrote: >> >> Kostya <[email protected]> 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?
Seems like an implicit rule to me. > Originally nobody cared about binary form distribution at all. Those nobodies have been removed. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
