On Sat, Apr 22, 2017 at 08:36:56PM +0200, Anton Khirnov wrote:
> Quoting Diego Biurrun (2017-04-22 17:48:09)
> > On Sat, Apr 22, 2017 at 11:25:10AM -0300, James Almer wrote:
> > > On 4/21/2017 7:05 AM, Diego Biurrun wrote:
> > > >On Fri, Apr 21, 2017 at 07:06:04AM +0200, wm4 wrote:
> > > >>On Thu, 20 Apr 2017 11:26:10 -0400
> > > >>Vittorio Giovara <[email protected]> wrote:
> > > >>
> > > >>>This should make these APIs simpler to use, and less error prone
> > > >>>in case the caller does not check they are valid, and makes them
> > > >>>more similar to other naming APIs.
> > > >>>---
> > > >>>This should help in the bug in avprobe found by Luca.
> > > >>>Sending as RFC since I believe we are allowed to break this API as we
> > > >>>did the version bump, but I'd like to be sure.
> > > >>>
> > > >>>  libavutil/pixdesc.c | 10 +++++-----
> > > >>>  libavutil/pixdesc.h | 10 +++++-----
> > > >>>  2 files changed, 10 insertions(+), 10 deletions(-)
> > > >>
> > > >>This is a serious API change and needs to go through the entire
> > > >>deprecation circus.
> > > >
> > > >We're still in the bump period...
> > > 
> > > That gives you free reign to play with offsets in public structs and with
> > > symbol availability, but not to change the signature or return value of
> > > functions in a way that existing downstream code will break. API breaks 
> > > are
> > > not the same as ABI breaks.
> > 
> > I know the difference between ABI and API. What I meant is that I consider
> > us still in API breaking season.
> 
> There never is an API breaking season. During a major bump we
> 1) break the ABI, requiring the callers to recompile against the newer
>    version
> 2) remove APIs which have been deprecated for sufficiently long
> 
> There is never ever any time when you're allowed to just change the API
> out of the blue with no warning or transition period (other than in
> extremely exceptional cases).

For the record: I think we used to have API breaking/instability periods
in the past. Might have been before we started doing all those deprecation
dances.

Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to