Hi folks! historically, Avro version numbers have had the form:
<data compatibility> . <major library version> . <minor library version> 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. For example, in the Java library when we make changes to public method signatures such that folks can't just swap out jar files of our implementation. While getting myself up to speed on the state of our release lines, I noticed we already have the 1.9 release line in a branch, with master set up for the next major library version. JIRA shows ~46 issues that are in 1.10 but not in a 1.9 release[1]. I haven't looked at all of them yet, but the few I sampled don't see to require a major version increment. I looked around our site and I also can't find anywhere that we've documented our version strings. I know I've been in discussions in other communities where our version strings have been surprising. e.g. folks had assumed they can do a low-effort upgrade from 1.7 to 1.8 only to find that there were documented incompatibilities and behavior changes. Are we actively planning on rolling out 1.10? (like, do we have a goal date?) I know that when 1.9 went out we EOLed 1.7 and 1.8 in part due to the overhead of trying to maintain multiple release lines (especially once that had so much baggage) while we're trying to reestablish good habits on release cadence. How many major version are we planning to keep going once 1.10 is ready? What do folks think about starting a CONTRIBUTING.md with some of these expectations? Is there a better place to track it? [1] : https://s.apache.org/71yqv
