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 > > > > > > > > > > > > > > > > > > > > > >
