For ease of maintenance, I think we should follow these rules: - one (mono)repo - each SDK has one stable version: main/master, that's available to be released on short notice - upon release, all changed SDKs get a new, appropriate, semantic version - all current SDK versions must be compatible with whatever is in the shared / documentation / ... folders
The only 'downside' is that these rules require proper pull request handling (only merge stuff that's stable/tested), but our track record on that is excellent. The idea to build a "this SDK supports these features" table is then one to pick up quickly after we implement our choice. Anyway, that's my opinion on the matter. Kind regards, Oscar -- Oscar Westra van Holthe - Kind <[email protected]> Op vr 13 jan. 2023 09:31 schreef Christophe Le Saëc <[email protected]>: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
