Second Vladimir's proposal // Generally speaking，we should decouple the dependence of the two projects on the master branch, Of course, if you merge into one repos, the issue of interdependence does not exist.
Best, Jincheng Sun Yogendra Sharma <[email protected]> 于2021年11月9日周二 下午3:28写道： > I agree with Vladimir. > > Although i am very new here but in my mind having one repository will > reduce lot of efforts while not necessarily it will reduce flexibility and > modularity of the the project. > > My initial impression is that we can achieve the same modularity > constraints even after merging the code into one repo. > > Get Outlook for Android<https://aka.ms/ghei36> > > ________________________________ > From: Vladimir Sitnikov <[email protected]> > Sent: Tuesday, November 9, 2021, 12:38 > To: Apache Calcite dev list > Subject: Re: DISCUSS: merge calcite-avatica and calcite repositories > > I know the below is too wordy, however, English is not my native language, > so I tend to overexplain and duplicate thoughts. > > Julian>To allow separate communities > > This is something I do not understand. > Let me be explicit: I am OK to maintain bits of avatica code when Calcite > fixes overlap with Avatica for some reason (e.g. throwing exceptions). > I am not OK with duplicating the same work just because someone else wants > to have a separate repository. > > I was maintaining and releasing multiple (four!) repositories for pgjdbc > when it was using Maven > (Maven was not able to release jre6, jre7, and jre8 artifacts from within a > single repository), and it was a big relief when the code was recollected > into a single repository again. > > That is why I am advocating for merging avatica code back. > > Julian>Splitting code into modules makes it easier to continue to splitting > > I agree it is worth having calcite-core and avatica as separate jar > artifacts. > It is even worth splitting "enumerable" out of calcite-core into its own > module. > However, I do not see how splitting the repositories helps. I do not expect > somebody to use calcite-avatica as a git submodule or something like that. > > Julian>to allow separate release schedules > > Here are the recent releases. > There's often a pattern that "Calcite release follows Avatica release". > It is even mentioned in the mails where someone suggests releasing Avatica, > then releasing Calcite". > > A notable exception was rel/avatica-1.16.0 which was not connected to the > release of Calcite. > The rest Avatica releases seem to be quite close to Calcite releases, so I > do not see what do we gain from "separate release schedules". > It looks like co-locating the release would be easier for both maintenance > overheads, testing, and consumption. > > > 2016-03-16 rel/calcite-avatica-1.7.0 > > 2016-03-17 calcite-1.7.0 > > 2016-03-15 rel/calcite-avatica-1.7.1 > > 2016-06-01 rel/calcite-avatica-1.8.0 > > 2016-06-08 calcite-1.8.0 > > > 2016-09-17 calcite-1.9.0 > > > 2016-10-07 calcite-1.10.0 > > 2016-10-27 rel/calcite-avatica-1.9.0 > > > 2017-01-03 calcite-1.11.0 > > 2017-03-20 calcite-1.12.0 > > 2017-05-23 rel/avatica-1.10.0 > > 2017-06-22 calcite-1.13.0 > > > 2017-09-27 calcite-1.14.0 > > 2017-12-05 calcite-1.15.0 > > 2018-03-06 rel/avatica-1.11.0 > > 2018-03-14 calcite-1.16.0 > > 2018-06-21 rel/avatica-1.12.0 > > 2018-07-16 calcite-1.17.0 > > 2018-11-29 rel/avatica-1.13.0 > > 2018-12-18 calcite-1.18.0 > > 2019-03-20 calcite-1.19.0 > > 2019-04-25 rel/avatica-1.14.0 > > 2019-05-09 rel/avatica-1.15.0 > > 2019-06-19 calcite-1.20.0 > > > 2019-09-06 calcite-1.21.0 > > 2019-12-19 rel/avatica-1.16.0 > > > 2020-05-23 calcite-1.23.0 > > 2020-06-22 rel/avatica-1.17.0 > > 2020-07-23 calcite-1.24.0 > 2020-08-22 calcite-1.25.0 > > 2020-10-06 calcite-1.26.0 > > > 2021-05-18 rel/avatica-1.18.0 > > 2021-06-03 calcite-1.27.0 > > 2021-10-04 rel/avatica-1.19.0 > > 2021-10-19 calcite-1.28.0 > > Julian>The last of these was particularly on my mind when we split Avatica > from > Calcite. > Julian>I was pleased to see, for example, Apache Phoenix using Avatica > successfully > (including building an ODBC driver) > > Does it really help Phonenix that we split repositories? > I am sure they should not really depend on the repositories. > How would their life be harder if we release the same set of artifacts and > jars from a single source tree? > > Julian>If Avatica had remained part of Calcite, both written in Java and > using the same build system and release process, > Julian>it’s less likely that Avatica-go would have happened > > Does Avatica-go use calcite-avatica repository? > So far it looks like Avatica-go uses > https://github.com/apache/calcite-avatica-go, and I do not suggest merging > it into calcite repository yet. > I do not see how merging calcite-avatica and calcite repositories would > block the evolution or emergence of avatica-go, avatica-rust, etc. > > Julian>release process > > I identified https://issues.apache.org/jira/browse/CALCITE-4881 "Calcite > release tags should have rel/... prefix as per the ASF requirements" > It looks like an unintentional breakage in > > https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 > caused > by the split. > > Vladimir > >
