On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <[email protected]> wrote: > 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. >
This is exactly what stopped me proceeding with the vote! One option is to split the monorepo to repo-per-sdk but this is a big task! The other viable option I see is to have just one branch (master) where all SDKs evolve in their own pace and bump their versions as they need. When a user asks for a maintaince release then a developer could create a branch from an earlier commit (e.g. from the respective tag/release) and apply the requested bug fixes. From my experience so far there were not many such requests. Such maintanance branches should be short lived - only for the requested big fix! Once a new release is tagged, e.g. release-rust-12.1.1, then the branch should be removed to avoid any confusions. Also such branches should be used only for the release of one SDK! I stopped working on the PR for the asf.yaml based website because I honestly have no idea how to support the split documentations per SDK per version in a monorepo... > > 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 > > > >
