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 as clear an obvious as we can on the site (maybe we should do this if we change to the standard scheme to?). The only reason I knew the scheme was because of an email Sean sent out describing it sometime last year(-ish). I like the idea of having the docs claim the spec version compatability. I think this is enough for covering the (hopefully unlikely or extremely rare) scenario in which we introduce breaking format changes. Regardless of whether or not the scheme changes, we have a structure in which we will make a major release that introduces breaking changes in one languages' bindings, but not another's. For example, maybe v1.10 makes breaking changes in the Java bindings, but no breaking changes are necessary in the Python bindings. This is not new, and not something I have a better alternative for, but I'm interested in hearing if others feel this is awkward or if others have suggestions for alternative approaches. I thought this was awkward when I first started working on the project, but after a little while felt it was worth it for the simplicity of having one version number for all the bindings. On Tue, Sep 10, 2019, 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 >
