[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Hendrik Leppkes
h.leppkes at gmail.com
Thu Aug 6 09:41:54 CEST 2015
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Thu, Jul 30, 2015 at 05:05:12PM +0200, Andreas Cadhalpun wrote:
> [...]
>
> IMO {
>
> trivial API, like identifers with different names or wrapers
> that are identical except having 1 argument less.
> That is API which does not require any testing to ensure its future
> function and correctness, should be kept as long as they are needed
> by a distribution.
I don't really mind if extra codec defines etc stick around for a
while, as long as they don't break things.
There is one part about the pixfmt compat code which does frequently
break in weird ways though, #define PixelFormat AVPixelFormat
PixelFormat is a very generic name, and that define has renamed
variables etc in not only a few projects before. ;)
>
> non trivial API, which has a volunteer maintaining and testing it
> and has one or more fate tests ensuring its fully functional and
> correct could be similarly kept as long as that person is testing
> and maintaining it
I would argue that for the sake of an easy to understand API, even
then they should be considered for removal at some point.
Usually there also is a reason we needed a new API, so the old API has
short-comings that an emulation may not be able to fix.
>
> the rest should be removed once it has been deprecated for a
> sufficient period of time.
>
> Its a bit unprofessional to break/remove API every 1-2 years
>
I think we can agree on that, but the functions under discussion here
are 3-4 years deprecated, so yay? :)
I don't remember when the last real API break happened though. The
last major bump was for ABI reasons, not strictly API, if I remember
correctly.
More information about the ffmpeg-devel
mailing list