Re: [DISCUSS] version numbers and where changes should land

+1 for incrementing the major number for library compatibility changes and decoupling the release versions across languages. I agree with the points that Sean made. This is confusing for users, and needlessly so because there is only one binary format and I don't think there are major pushes to in

Re: [DISCUSS] version numbers and where changes should land

> So, as I understand it. The whole 1.x version should be binary compatible. the term "binary compatible" is overloaded, thanks to our participation in the Java ecosystem. Every data file written in Avro 1.y is intended to be readable by every other Avro 1.y release, regardless of language. That i

Re: [DISCUSS] version numbers and where changes should land

So, as I understand it. The whole 1.x version should be binary compatible. So anything is written with Java 1.x should be readable with Python 1.x. We've been working on extending the integration tests as well. Not all languages support all the features, for example, many languages lack support fo

Re: [DISCUSS] version numbers and where changes should land

Counterpoint on independently versioning the various languages. Do we know if Python Avro X works with Java Avro Y as it is? It seems like we already get surprised pretty often when they don't. If we stop including the "data compatibility version" or whatever we're calling the first number, we'll

Re: [DISCUSS] version numbers and where changes should land

Bringing my comment from the JIRA ticket here for discussion: > "One argument against semantic versioning is the fact that Avro supports 9 language APIs, so if let's say C++ breaks its backwards compatibility should we move the version number up for every single language? Sounds like a burden and

Re: [DISCUSS] version numbers and where changes should land

Hello! Resurrecting -- I think this was the last thread bringing up this issue! Since we've talked about releasing 1.10.x in May, and it's a nice round number... what do you think about 1) finally dropping the prefix for the "specification version" and calling it Avro 10.x 2) committing to sema

Re: [DISCUSS] version numbers and where changes should land

Thanks Sean for bringing this up. For the 1.9 branch there were some incompatible changes in the API with respect to 1.8.2. We've removed Jackson and Netty from the public API. This is actually breaking some of the builds

Re: [DISCUSS] version numbers and where changes should land

> What would it look like if we *did* have to make an incompatible data format change after adopting "conventional" library version strings? Let's call these format v1 and v2. The library must produce v1 by default, so it's a matter of having support for writing v2. When the default changes to v2,

Re: [DISCUSS] version numbers and where changes should land

I also +1 a standard versioning scheme that bumps the first number for breaking changes. This has become a standard for libraries, so I think it is confusing for our users that we have a custom scheme. That being said, if we decide to keep our custom scheme, we should definitely make that scheme a

Re: [DISCUSS] version numbers and where changes should land

What would it look like if we *did* have to make an incompatible data format change after adopting "conventional" library version strings? What if we version the specification independent from the libraries and then have the docs for the libraries claim spec version compatibility? On Tue, Sep 10,

Re: [DISCUSS] version numbers and where changes should land

+1 for changing the version strings to follow a more standard convention. We don't have any breaking format changes, so I think it is expected that the format compatibility version won't change. On Tue, Sep 10, 2019 at 7:28 AM Sean Busbey wrote: > Hi folks! > > historically, Avro version numbers

[DISCUSS] version numbers and where changes should land

Hi folks! historically, Avro version numbers have had the form: . . That is, the first number says wether or not we expect data serialization to be compatible, and the second to say wether we expect some library will be backwards incompatible however that's defined for the library's language.