On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote: > On Tue, Dec 6, 2016 at 2:43 AM, Diego Biurrun <[email protected]> wrote: > > On Tue, Dec 06, 2016 at 12:27:22AM -0500, Vittorio Giovara wrote: > >> --- a/libavdevice/version.h > >> +++ b/libavdevice/version.h > >> @@ -27,8 +27,8 @@ > >> > >> -#define LIBAVDEVICE_VERSION_MAJOR 56 > >> -#define LIBAVDEVICE_VERSION_MINOR 1 > >> +#define LIBAVDEVICE_VERSION_MAJOR 57 > >> +#define LIBAVDEVICE_VERSION_MINOR 0 > >> #define LIBAVDEVICE_VERSION_MICRO 0 > >> > >> --- a/libavresample/version.h > >> +++ b/libavresample/version.h > >> @@ -27,7 +27,7 @@ > >> > >> -#define LIBAVRESAMPLE_VERSION_MAJOR 3 > >> +#define LIBAVRESAMPLE_VERSION_MAJOR 4 > >> #define LIBAVRESAMPLE_VERSION_MINOR 0 > >> #define LIBAVRESAMPLE_VERSION_MICRO 0 > >> > >> --- a/libswscale/version.h > >> +++ b/libswscale/version.h > >> @@ -26,7 +26,7 @@ > >> > >> -#define LIBSWSCALE_VERSION_MAJOR 4 > >> +#define LIBSWSCALE_VERSION_MAJOR 5 > >> #define LIBSWSCALE_VERSION_MINOR 0 > >> #define LIBSWSCALE_VERSION_MICRO 0 > > > > These bumps seem gratuitous, there are no deprecated APIs in these > > libraries. > > I'm aware there are not ABI-changes in those libs, but historically > we've always bumped every library to avoid any possible version > conflict. See for example 6d3ea1957f681b3bf9c752e6d21a501cc8d4180d or > 3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c. While most of the root > causes for those incompatibilities have been long resolved, it's still > a good practice and relatively harmless to do.
There was this idea of a single version number for all libraries. Maybe it's time to revisit it? > > Also, lots of tests currently break if you bump all version numbers because > > the output of the framecrc muxer changes. That will have to be addressed. > > Anton knows the exact reason and wanted to make a decision which way to > > resolve this. > > > > https://oracle.libav.org/x86_64-linux-version-bump/20161204165430 > > This is because that test disables a particular API which changes the > test duration, which is not yet included in this removal. I suggest we resolve this in the not-so-distant future and try to maintain a green version-bump Oracle instance. > Oracle is fully green https://oracle.libav.org/. You wish .. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
