Indeed, "Commons tests" embeds avro files that aims to be used in tests for every SDKs, but we also can add meta information to minimum SDK version is required for this tests. Concretely, with this files <https://github.com/apache/avro/pull/1850/files>, adding "meta.properties" on each share/test/data/schemas/ subfolder that would contains "sdk.version.min=12" ... So, each SDK would automatically select files that it have to test. And finally, there may have no real issue with other "share" file (i see lot of them not modified since many years on github)
Le jeu. 12 janv. 2023 à 17:53, Martin Grigorov <[email protected]> a écrit : > On Thu, Jan 12, 2023, 17:33 Christophe Le Saëc <[email protected]> wrote: > > > So, if i take the latest one; i could have > > lang/java 13.1 > > lang/python 11.2 > > lang/rust 12.3 > > > > So what will contains *share* folder if it should integrates some updates > > between 11 & 12 and between 12 & 13 ? (some sub-folder share/11 ... ? to > > allow lang/java to use share/13, lang/python to use share/11 ... ? > > > > Do you mean "to support changes in different versions of the specification" > or in the common tests? > > I see the common tests as something that any SDK can decide to implement a > specific test at any time no matter what is the SDK's version. > > > > Le jeu. 12 janv. 2023 à 15:19, Martin Grigorov <[email protected]> a > > écrit : > > > > > On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <[email protected] > > > > > wrote: > > > > > > > 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. > > > > > > > > > > I don't see the problem. > > > The main branch in the monorepo will consists of SDKs with various > > > versions, but each SDK will have just one version at any time. > > > Older versions will be in the release tags. > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
