Hi folks, We're almost there. https://cwiki.apache.org/confluence/display/ARROW/Arrow+2.0.0+Release shows 11 open and 17 in progress issues for 2.0. No blockers, but there are still two nightly build failures ticketed (ARROW-10175 (pyarrow/hdfs), ARROW-10177 (gandiva xenial)) and perhaps others showing up in the most recent nightly build report.
I suspect we will need most of tomorrow to resolve many of those issues. Given that, I doubt we'll have a first release candidate built and up for a vote tomorrow, but I'm hopeful that we'll be release-ready by the end of the day. Thoughts, everyone? Krisztián (who has bravely agreed to be the release manager again): what do you think? Neal On Wed, Oct 7, 2020 at 4:15 PM Krisztián Szűcs <szucs.kriszt...@gmail.com> wrote: > There is still some work left to make the packaging builds pass on the > PR. Considering how close we are to the release I find it risky to > include that change to 2.0. So I'm in favor of postponing it to 3.0. > > > On Wed, Oct 7, 2020 at 11:10 PM Micah Kornfield <emkornfi...@gmail.com> > wrote: > > > > I agree with Antoine that we shouldn't be making changes to dependency > > versions so close to a release. This is consistent with other types of > > changes that could have a potentially large blast radius > > > > I don't have a strong opinion on what version we end up with though > (would > > need to do more research on compatibility guarantees) > > > > Micah > > > > On Wednesday, October 7, 2020, Neal Richardson < > neal.p.richard...@gmail.com> > > wrote: > > > > > On Wed, Oct 7, 2020 at 1:11 PM Antoine Pitrou <anto...@python.org> > wrote: > > > > > > > > > > > Le 07/10/2020 à 21:55, Neal Richardson a écrit : > > > > > * The only version that is a requirement is > > > > > > > > > > > > > https://github.com/apache/arrow/pull/8325/files#diff-2420b0c5b6bdad921f1d538f92d64b59R2516 > > > > , > > > > > and so that's the one we're concerned about increasing. If we can > keep > > > it > > > > > low with an #ifdef, great. That said, I have no idea how slow > people > > > are > > > > to > > > > > update gRPC, or even what constitutes "old", so I can't say how > much > > > > extra > > > > > complication it is worth to support old versions. > > > > > > > > Well, the gRPC version provided by Ubuntu 20.04 is 1.16.1. > > > > > > > > > > According to > > > > > > > https://github.com/apache/arrow/blob/master/cpp/cmake_modules/ThirdpartyToolchain.cmake#L2509 > > > , > > > we already require 1.17, which is newer than that. And we've required > that > > > for the last year: > > > > > > > https://github.com/apache/arrow/commit/a70cf783364b140cab172e1851b563295c46e333 > > > > > > > > > > > > > > > * However, provided that the bundled build_grpc cmake macro works > > > (surely > > > > > we test that somewhere right?), if someone has > > > > ARROW_DEPENDENCY_SOURCE=AUTO > > > > > *and* they have old gRPC on their system, instead of a build > failure > > > > > they'll just get a slower build with the bundled grpc included. > That's > > > > not > > > > > a bad experience, and if the user doesn't like it, presumably they > can > > > > > upgrade system gRPC and rebuild. > > > > > > > > How do you upgrade system gRPC without potentially breaking other > > > > packages that rely on it? If it's a system library, it's generally > > > > recommended to follow system-dictated lifecycles. > > > > > > > > I am not saying that we should ensure compatibility with antiquated > > > > versions of gRPC, but being incompatible with the version provided by > > > > Ubuntu 20.04 (a 6-month old distribution) may be exaggerated. > > > > > > > > Regards > > > > > > > > Antoine. > > > > > > > >
