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, 2019 at 3:55 PM Ryan Blue <rb...@netflix.com.invalid> wrote: > > +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
