Due to abovementioned compatibility guarantees, removing APIs is an involved process that should only be undertaken with good reason. Typically a deficient, restrictive, or otherwise inadequate API is replaced by a superior one, though it does at times happen that we remove an API without any replacement (e.g. when the feature it provides is deemed not worth the maintenance effort, out of scope of the project, fundamentally flawed, etc.).
The removal has two steps - first the API is deprecated and scheduled for removal, but remains present and functional. The second step is actually removing the API - this is described in Major version bumps.
To deprecate an API you should signal to our users that they should stop using it. E.g. if you intend to remove struct members or functions, you should mark them with attribute_deprecated. When this cannot be done, it may be possible to detect the use of the deprecated API at runtime and print a warning (though take care not to print it too often). You should also document the deprecation (and the replacement, if applicable) in the relevant Doxygen documentation block.
Finally, you should define a deprecation guard along the lines of #define FF_API_<FOO> (LIBAVBAR_VERSION_MAJOR < XX) (where XX is the major version in which the API will be removed) in libavbar/version_major.h (version.h in case of libavutil). Then wrap all uses of the deprecated API in #if FF_API_<FOO> .... #endif, so that the code will automatically get disabled once the major version reaches XX. You can also use FF_DISABLE_DEPRECATION_WARNINGS and FF_ENABLE_DEPRECATION_WARNINGS to suppress compiler deprecation warnings inside these guards. You should test that the code compiles and works with the guard macro evaluating to both true and false.
标签：deprecation,FF,ffmpeg,Removing,interfaces,should,API,version,deprecated From： https://www.cnblogs.com/sathcal/p/18537802