On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
<mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
