On Thu, Jan 12, 2023 at 3:12 PM Christophe Le Saëc <chles...@gmail.com> 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 <mgrigo...@apache.org> a > écrit : > > > On Wed, Jan 11, 2023 at 9:27 PM Ryan Skraba <r...@skraba.com> 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 > > > <khrystyna.popad...@gmail.com> wrote: > > > > > > > > +1 for separating out the releasesе too > > > > > > > > On Sat, Jan 7, 2023 at 4:46 AM Ryan Blue <b...@tabular.io> 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 <tjwperk...@gmail.com> > > > wrote: > > > > > > > > > > > On Wed, Jan 4, 2023 at 1:15 PM Ryan Skraba <r...@skraba.com> > > 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 > > > > > > > > > > >
