On Mon, Dec 2, 2013 at 1:56 PM, Philip Zeyliger <phi...@cloudera.com> wrote: > It sounds like you're proposing to break language API compatibility. Are > you also proposing to break wire compatibility for Avro HTTP RPC, Avro Netty > RPC, and/or Avro datafiles?
We should be able to provide back-compatibility. When current APIs cannot be back-compatibly extended, new APIs can be added. Old APIs may be deprecated but should be retained for a while. Data files written by 1.x should be readable by 2.x. Forward compatibility may not be possible when new schema features are used. Data files written in 2.x may not be readable by 1.x. Perhaps we could add a mode that forces 2.x to write a 1.x format file. RPC interoperability requires that 2.x be able to both read and write 1.x format. So long as a 1.x protocol is used, then 1.x and 2.x clients and servers might be able to interoperate using 1.x wire formats. But when 2.x schema features are used this may not be possible. Perhaps we should proceed by making back-compatibility (ability to read 1.x) a requirement, then adding interoperabilty features (ability to write 1.x) as needed? Should we require that all new schema features (named unions, extensions, date primitive, etc,) have a lossless translation to a 1.x schema? Doug
