[
https://issues.apache.org/jira/browse/AVRO-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016991#comment-17016991
]
Ryan Skraba commented on AVRO-2687:
-----------------------------------
Some info on [Avro
versioning|https://lists.apache.org/x/thread.html/16b68748464a7ce7232f12bbbf781cbfd5de982785d5648b6c564cc9@%3Cdev.avro.apache.org%3E]
from the mailing list. It looks like everyone agrees that current versioning
is unexpected.
Keep in mind that the binary format for Avro has been extraordinarily stable
across 1.X versions, just the language-specific APIs tend to change and cause
breakage. In that light, AVRO-2682 is discussing whether an older Avro runtime
should be forwards-compatible with future Avro-generated code -- which isn't a
goal even with strict semver!
> Semantic Versioning
> -------------------
>
> Key: AVRO-2687
> URL: https://issues.apache.org/jira/browse/AVRO-2687
> Project: Apache Avro
> Issue Type: Improvement
> Reporter: Elliotte Rusty Harold
> Priority: Major
>
> API level and other incompatibility between Avro minor versions is causing
> significant problems for Apache Beam. E.g.
> [https://github.com/apache/beam/pull/9779]
>
> Stable releases that don't break backwards compatibility would help us and
> other users a great deal. E.g. not removing joda.time support in 1.10.
>
> Absent that, at a minimum Avro should update its major version for any API
> breaking change. E.g. 1.9 should have been 2.0 because it was not API
> compatible with 1.8. In the case of Avro, this would apply not just to the
> public Java API but also to the serialization format.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
