Hi, On Fri, Apr 8, 2011 at 10:15 AM, Anton Khirnov <[email protected]> wrote: > On Fri, Apr 08, 2011 at 10:10:18AM -0400, Ronald S. Bultje wrote: >> On Fri, Apr 8, 2011 at 9:43 AM, Anton Khirnov <[email protected]> wrote: >> > On Fri, Apr 08, 2011 at 07:39:52AM -0400, Ronald S. Bultje wrote: >> >> On Fri, Apr 8, 2011 at 5:48 AM, Anton Khirnov <[email protected]> wrote: >> >> > --- >> >> > libavformat/avformat.h | 4 +++- >> >> > libavformat/utils.c | 4 ++++ >> >> > libavformat/version.h | 3 +++ >> >> > 3 files changed, 10 insertions(+), 1 deletions(-) >> >> >> >> Any reason we don't want to remove it at the next one already, going >> >> by the evil "release, bump, release again" plan? >> >> >> > >> > As you already know =p, I think our policy should be to remove old stuff >> > only after a sufficiently (at least ~0.5y) long transition period. >> >> These *2() functions have been out for a few months, so it's long >> enough. I've keen on removing as much old cruft as possible. >> >> (It's not like this is critical API that every application definitely >> uses, unlike say avcodec_decode_audioX() or so... The chance of real >> problems is relatively small.) > > Only one month. > > Don't forget that we already have a bad reputation for breaking > compatibility often (undeserved, but still...). I'd prefer to be more > conservative with those things, unless they obstruct progress. That is > certainly not the case here.
Fair enough, I already OK'ed the patch. But if the code was bigger or it would obstruct reordering of stuff in structs (i.e. ABI) I'd make a bigger deal about it maybe. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
