+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 <bus...@apache.org> wrote: > 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 > -- Ryan Blue Software Engineer Netflix
