On Sun, 18 Dec 2011 21:10:43 +0200, Uoti Urpala <uoti.urp...@pp1.inet.fi> wrote: > 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? >
I suppose we could make a micro version bump on deprecations, that should solve this problem. -- Anton Khirnov _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
