With one github repo; how to manage share <https://github.com/apache/avro/tree/master/share> folder ? i mean if one version need updates on this repo but not the older.
As an example, this JIRA AVRO-3591 <https://issues.apache.org/jira/browse/AVRO-3591> aims to create commons inter sdk unit tests (The PR <https://github.com/apache/avro/pull/1850> add some files on share folder); commons tests could be valid for a version but not for an older one. Le jeu. 12 janv. 2023 à 12:24, Martin Grigorov <[email protected]> a écrit : > 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 > > > > > > >
