Hey -- how does this sound for rolling out this strategy. 1) No changes to 1.11 branch. We can release 1.11.2 to bring some of the immediate bug and security fixes.
2) The next major release of Avro will be 12.0.0 for the specification and all SDK (except maybe Rust) and we'll start following semantic versioning per-SDK, with "traditional" major.minor.patch versions. 2b) The specification (and probably some other documentation) now has a version separate from the SDKs, and it'll probably stay at 12.x forever as long as we call this project Avro (no breaking changes). I agree it would be great to have a "compliance" matrix on the website! 2c) We can expect more active/experimental SDKs to go to 13.x, 14.x when breaking changes are introduced, while stable and less active SDKs to go to 12.1.x, 12.2.x ... That's fine and that's life if the major version isn't the same for SDKs -- bumping the major version doesn't mean "better". We can decide whether this is working for us during 12.x, and figure out how to address interoperability questions (between versions and between SDKs). 3) We'll have to figure out a navigation system per SDK for the website, but we'll have a bit of time to do that. Hopefully it doesn't break Martin's current investigation with branch release artifacts. 4) We can decide how many major versions remain supported per-sdk. In my opinion, the "semantic versioning" VOTE is a pre-requisite to the SDK/splitting vote -- currently I'd be confused if I saw a 1.12 Avro python SDK available, but not a Java one. The big change to 12.x makes this a bit more obvious (and is also something devs have been asking for since I've been with the project!) Another thing I'd like to talk about before calling a VOTE is github branches... I've been trying to wrap my head around it, but it's still a bit unclear to me how we should manage this in a mono-repo. In any case, I'm motivated to keep this discussion going! :D I'd definitely vote +1 on the "should we?" but "and how?" could use a bit of refinement. All my best, Ryan On Wed, Jan 11, 2023 at 10:12 AM Khrystyna Popadyuk <[email protected]> wrote: > > +1 for separating out the releasesе too > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <[email protected]> wrote: > > > +1 for separating out the releases and starting a vote on just that. We can > > debate the other details as we go. > > > > On Thu, Jan 5, 2023 at 12:25 PM Tim Perkins <[email protected]> wrote: > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <[email protected]> wrote: > > > > > > > Maybe a good way to get to consensus would be to list the possible > > > > actions we could take, and prioritize them? > > > > > > > > > > One of the actions that I would like to see is the compilation of which > > > parts of the spec each language implements. This would be a useful > > addition > > > to the documentation. > > > > > > If we compile this table it may be that it requires a lot of footnotes > > and > > > qualifications for differences in how languages implement the spec, but > > > overall it would still be useful to identify gaps, highlight differences, > > > and perhaps ultimately drive more compatibility. > > > > > > > > > -- > > Ryan Blue > > Tabular > >
