On 4/6/11 11:27 PM, Ronald S. Bultje wrote:
Hi,
On Wed, Apr 6, 2011 at 2:34 AM, Anton Khirnov<[email protected]> wrote:
They've been deprecated very recently.
---
libavformat/version.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/version.h b/libavformat/version.h
index 1d25bfd..c5f3223 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -90,7 +90,7 @@
#define FF_API_SYMVER (LIBAVFORMAT_VERSION_MAJOR< 53)
#endif
#ifndef FF_API_OLD_AVIO
-#define FF_API_OLD_AVIO (LIBAVFORMAT_VERSION_MAJOR< 53)
+#define FF_API_OLD_AVIO (LIBAVFORMAT_VERSION_MAJOR< 54)
#endif
#ifndef FF_API_INDEX_BUILT
#define FF_API_INDEX_BUILT (LIBAVFORMAT_VERSION_MAJOR< 53)
Distro people please help out here :-).
My impression is that they want symbols in here for another couple of
_releases_, not _majors_. I don't think changing the major here is a
good idea, it's just the same old cruft around for longer. If we want
to keep the symbols in release X, then simply release X without the
major bump. Once we're ready to delete the symbols from our binaries,
bump major, done.
I like the idea of keeping now deprecated stuff around for a bit more.
As I'd like to have the uniform version I discussed early.
Keeping compat stuff across even/odd releases might be useful for
developers and in our current case might be useful in order to sort out
the low level io abstraction api that now we know is used as is.
regarding bumping or not bumping the major depends. I like the idea of
giving a last call, but you are right, we could release 0.7 with the
same major version and once we are fully happy release a 0.8 breaking
completely 0.6 while keeping the api introduced by 0.7.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
