On Mon, 19 Dec 2016 12:57:23 +0100 Anton Khirnov <[email protected]> wrote:
> Quoting Diego Biurrun (2016-12-06 23:15:48) > > 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? > > I do not think it is a good idea. IMO the libraries should be growing more > separate, not less. > Well, what do you want to work towards? I'd say either split the git repo, or acknowledge that the libs are not actually independent from each other. In the current state, having a single version number would be less of a pain. I see no reason why I should deal with 12 version numbers (lavc, lavf, sws, avr, lavfi, lavu, plus runtime versions for each), when it makes no sense to mix these libs. Only distros do this anyway, and I can't think of a reason why they would, other than being obstinate. If you go ahead and split the git repo, readding individual version numbers would be trivial. But even then you'd probably want a single ABI version number or so to avoid chaos. Especially the interface between lavf and lavc is extremely fragile due to the nature of multimedia, and nobody is going to really test different combinations of them to make sure they don't break. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
