Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: > On Sun, 2011-12-18 at 19:29 +0100, Anton Khirnov wrote: >> On Sun, 18 Dec 2011 19:53:00 +0200, Uoti Urpala <uoti.urp...@pp1.inet.fi> >> wrote: >> > On Sun, 2011-12-18 at 17:20 +0000, Mans Rullgard wrote: >> > > - int age; >> > > + attribute_deprecated int age; >> > >> > IMO setting attribute_deprecated immediately is a bad idea. Unless you >> > want your application to break when used with libavcodec compiled >> > yesterday you can't remove mentions of the field immediately. Thus >> > warnings like this produce clutter that only hides real issues unless >> > you disable deprecation warnings completely or add redundant version >> > checks. In this case removing code setting the field now rather than >> > later doesn't even give any benefit whatsoever: setting it causes no >> > harm and there is no new API to test. >> > >> >> If we don't mark it as deprecated, how are the users supposed to notice >> it is? > > So a user checks compiler warnings and notices that it is deprecated. He > determines that the correct action is to do nothing for now. Then > there's a warning again the next time he compiles the program. Is the > user really supposed to notice it again every day for the next half a > year? > > Adding an entry to APIchanges is a more appropriate way to communicate > this (this was missing from Måns's patch).
I'll add that, but it's not necessary for patch review. > 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. The next release will have the field marked deprecated, and the one after that will remove it. That's how we roll. -- Måns Rullgård m...@mansr.com _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
