+1 (binding) I think this is a good step forward to acknowledge how we want to move forward and framing for a forward incompatible release.
As to the concerns Micah is raising, I feel like those are more the mechanics of how we would release, but I feel this vote is more to codify the directional alignment. On Tue, Jul 7, 2026 at 8:33 AM Antoine Pitrou <[email protected]> wrote: > > Thanks Micah. I was hesitating to -1 as well, because the proposal > leaves some critical elements undefined (though thanks for doing it!). > > I'm also not sure about the messaging as, given our current policy, > people may expect "Parquet 3" to be an entirely incompatible > rearchitecture of the format, not just new optional encodings. > > Regards > > Antoine. > > > Le 07/07/2026 à 07:20, Micah Kornfield a écrit : > > -1. I'm not actually sure what the practical outcome of this vote means. > > I agree from a feature grouping perspective using the parquet format > > version release makes sense. I don't agree it should be a single number > > (this doesn't account for forward compatible changes that a writer might > > not want to enable immediately, e.g. new sort orders). > > > > A way of addressing this Ryan is if you could you post a PR modifying > > https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md to > > what the actual change in process is, so we can vote on that? > > > > Open questions in my mind are: > > * Will the community vote be separate from a major/minor release of the > > format? > > * Are we going to maintain two branches of the format or something else? > > * Are we going to block breaking changes from being merged and delay > major > > release of the format? > > * What are the criteria for closing a major format version? > > > > If some of these fall in later parts of the conversation, then they don't > > need to be included in the PR. > > > > Thanks, > > Micah > > > > > > > > On Mon, Jul 6, 2026 at 4:53 PM Ryan Blue <[email protected]> wrote: > > > >> Hi everyone, > >> > >> This is a vote to conclude the discussion about the future of Parquet > >> versioning. We’ve reached the end of that discussion thread and there > is a > >> clear preference in the community for using increasing version numbers > to > >> release forward-incompatible changes. > >> > >> This vote is to confirm the choice to use version numbers. Specifically, > >> > >> - We will accumulate forward-incompatible changes targeted at the > next > >> major version of the Parquet spec (3, 4, etc.) > >> - New forward-incompatible changes will automatically go into the > next > >> major version > >> - We will have a community vote to close and adopt each major > version > >> > >> If you’re familiar with Iceberg, this is what we’ve referred to as the > >> “Iceberg model” (although we inherited it from Parquet). > >> > >> Please vote in the next 72 hours: > >> > >> [ ] +1: Adopt versions for forward-incompatible changes > >> [ ] +0: Not going to block, but prefer . . . > >> [ ] -1: Do not adopt versions for forward-incompatible changes because > . . > >> . > >> > >> Glad to see this moving forward! > >> > >> Ryan > >> > > > > >
