Hello, I'm strongly in favor of enabling a passing build on PRs like #3610 What is the mechanism to track what version of parquet-format, parquet-java depends on? Is there a check to track discrepancies or drift? A POC would help clarify this.
Separately, I think we should also make more frequent releases of parquet-format. That could be formalized in our new versioning process. In particular every time we merge a new change to the thrift file, we could systematically create a new minor-patch release of Parquet format with the addition in preview or experimental depending where we're at. The documentation would clarify whether a new optional field is part of the official version yet or not. That would decouple publishing versioned artifacts and declaring something part of the next official version. (and independently of that we can either depend on a tagged version of the file rather than the maven artifact) On Fri, Jul 24, 2026 at 7:42 AM Russell Spitzer <[email protected]> wrote: > +1 for all the reasons stated above. > > On Thu, Jul 23, 2026 at 10:21 PM Gang Wu <[email protected]> wrote: > > > I'm in favor of this proposal. > > > > PoCing a Java implementation in the current setup is painful. CI builds > > will > > always fail, and PRs cannot merge before releasing a new parquet-format > > jar. > > > > Best, > > Gang > > > > On Tue, Jul 21, 2026 at 8:46 PM Antoine Pitrou <[email protected]> > wrote: > > > > > Le 21/07/2026 à 14:05, Andrew Lamb a écrit : > > > > As a maintainer of arrow-rs 's Parquet implementation, my experience > > has > > > > been that our copy of parquet.thrift (rather than a dependency) has > > > worked > > > > great, and we have never had an issue with this scheme that I can > > > remember > > > > > > We do the same in Arrow C++ and never had any problem with it either. > > > > > > Regards > > > > > > Antoine. > > > > > > > > > > > > > > Andrew > > > > > > > > On Tue, Jul 21, 2026 at 7:19 AM Divjot Arora via dev < > > > [email protected]> > > > > wrote: > > > > > > > >> Hi folks, > > > >> > > > >> The parquet-java project currently declares a dependency on a pinned > > > >> version of parquet-format and dynamically pulls in the > parquet.thrift > > > file > > > >> for the pinned version. > > > >> This makes it impossible to validate and merge PRs to support new > > > features > > > >> that have been merged into parquet-format but are not yet part of an > > > >> official parquet-format > > > >> release (https://github.com/apache/parquet-java/pull/3610 is an > > > example). > > > >> In contrast, the arrow-rs and arrow-cpp projects have a vendored > copy > > of > > > >> parquet.thrift in their > > > >> repos, which allows them to bypass this problem. What do folks think > > > about > > > >> adopting this vendored approach in parquet-java? > > > >> > > > >> -- Div Arora > > > >> > > > > > > > > > > > > > > > >
