On Sun, 2011-12-18 at 19:22 +0000, Måns Rullgård wrote: > Uoti Urpala <[email protected]> writes: > > Unconditional attribute_deprecated can be used once it's appropriate > > to expect the users to actually remove use of the deprecated symbol > > when they see the warning. > > I fully expect any user tracking git to stay current with API changes.
"Stay current" in the sense of removing support for anything _but_ latest Libav git? That doesn't make much sense. Neither would adding useless version checks before you actually drop code for the older API. > The next release will have the field marked deprecated, and the one > after that will remove it. That's how we roll. I have no objection to that. But it doesn't require you to start immediately spamming warnings even _before_ that next release (if there's still a full release cycle left after that before it's really necessary to change). You could use deprecated_avcodec54 or something like that to only start enabled-by-default deprecation warnings under that major version. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
