Suppose that the dependencies were uploaded to the RC site, such as https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.23.0-rc0/ <https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.23.0-rc0/>. Then people voting on the RC could compare those dependencies with the dependences of the previous release.
It’s a single line in bash, something like this: diff -y <(curl https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc0/dep.txt) . <(curl https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.23.0-rc0/dep.txt) . (For some reason 1.24 and later don’t appear on the site. I expect Apache INFRA has been tinkering with something. But I expect the problem can be fixed.) Julian > On Dec 4, 2021, at 3:47 AM, Michael Mior <mm...@apache.org> wrote: > > It can't really be fully automatic because sometimes we may want to > legitimately add a new dependency. I would be interested in thinking > about how we could make sure unwanted dependencies don't creep in. > Part of the problem is that the release manager may not know what > dependencies should or shouldn't be added. I see a few possible ways > around this: > > 1. Make sure that when a new dependency is added, a commit explicitly > mentions the new dependency in some format that is grepable. Any > dependency not found in this way should be discussed. > 2. Include a list of new dependencies with the RC announcement, giving > others a chance to chime in. > 3. Make some step of the release process fail if new dependencies are > added since the last release unless a specific flag is given. The > purpose of this flag would be to acknowledge that the new dependencies > are in fact, intended to be added. > > -- > Michael Mior > mm...@apache.org > > Le sam. 4 déc. 2021 à 01:27, Jacques Nadeau <jacq...@apache.org> a écrit : >> >> Any opinions on whether we should formalize into some kind of release >> verification step (manual or automatic)? >> >> On Thu, Dec 2, 2021 at 5:22 PM Julian Hyde <jhyde.apa...@gmail.com> wrote: >> >>> It’s quite easy to script. For example, >>> >>> git checkout calcite-1.27.0 >>> ./gradlew dependencies > /tmp/d27.txt >>> git checkout calcite-1.28.0 >>> ./gradlew dependencies > /tmp/d28.txt >>> diff /tmp/d2{7,8}.txt >>> >>> I posted the output at >>> https://gist.github.com/julianhyde/9ca5915bfb91494b7f91405ad15d698e < >>> https://gist.github.com/julianhyde/9ca5915bfb91494b7f91405ad15d698e>. >>> >>> Julian >>> >>> >>>> On Nov 30, 2021, at 3:40 PM, Jacques Nadeau <jacq...@apache.org> wrote: >>>> >>>> Nice. >>>> >>>> Anyone know if there is a tool to fingerprint dependencies between >>> releases >>>> so we can avoid introducing new dependencies accidentally? >>>> >>>> On Tue, Nov 30, 2021 at 1:26 PM Stamatis Zampetakis <zabe...@gmail.com> >>>> wrote: >>>> >>>>> It seems that Vladimir fixed this already in [1]. >>>>> >>>>> [1] >>>>> >>>>> >>> https://github.com/apache/calcite/commit/f3e2f041567e35e65464676d3171db3b5f2ddf9c >>>>> >>>>> On Tue, Nov 30, 2021 at 7:50 PM Jacques Nadeau <jacq...@apache.org> >>> wrote: >>>>> >>>>>> Can you file a JIRA? We should address before 1.29. >>>>>> >>>>>> On Tue, Nov 30, 2021 at 6:40 AM Zoltan Farkas >>>>> <zolyfar...@yahoo.com.invalid >>>>>>> >>>>>> wrote: >>>>>> >>>>>>> According to the published pom it is a direct dependency: >>>>>>> >>>>>> >>>>> >>> https://repo1.maven.org/maven2/org/apache/calcite/calcite-core/1.28.0/calcite-core-1.28.0.pom >>>>>>> < >>>>>>> >>>>>> >>>>> >>> https://repo1.maven.org/maven2/org/apache/calcite/calcite-core/1.28.0/calcite-core-1.28.0.pom >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 29, 2021, at 11:41 PM, Vladimir Sitnikov < >>>>>>> sitnikov.vladi...@gmail.com> wrote: >>>>>>>> >>>>>>>>> since core/src/kotlin does not exist yet. >>>>>>>> >>>>>>>> I mean core/src/main/kotlin does not exist yet >>>>>>>> >>>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>>
