> 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, then that behavior change would require a major version increase to signal changes to compatibility. I think we would also want clear documentation for each version that shows what versions of the format it can read, write, and what it will use by default. A table on the site would work. On Tue, Sep 10, 2019 at 2:51 PM Sean Busbey <bus...@apache.org> wrote: > 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 > -- Ryan Blue Software Engineer Netflix
