+1 (binding) from me, and I'll also take a minute to reply to clarify the vote in response to Micah.
--- Micah, did you mean -0 to ask for clarification? It doesn't sound like you object to any of the specifics that I listed but would like more details about versioning the parquet-format artifact? This vote addresses what I called out as the contentious issues in the other thread a couple weeks ago: how to create and release feature bundles and how to label them. I called these out in the vote summary as "targeted at the next major version" (labeling) and "community vote to close and adopt each major version". The reason I call out "major version" is that it is the main decision point. We can definitely use minor or patch version numbers, but the focus here is on forward-incompatible changes that result in a major version bump. Minor version changes, by definition, do not break forward compatibility, so they aren't actually part of compatibility level checks although they may be useful for other purposes. Only the major version defines a compatibility level (outlined by Alkis' email). The first 3 specific questions in Micah's reply are mostly about how to map the major version compatibility level to parquet-format releases. I don't want to get too distracted by artifact versioning, since the main thing is how we deal with breaking spec changes (accumulate them and vote to release them as a group). I think there's a reasonable mapping to Parquet format release numbers, like bumping the minor version when we add a compatible change. This is actually the _current_ versioning scheme! But keep in mind that the way spec versions evolve is not the same as how software APIs evolve so "semver" has to be reinterpreted -- let's use a separate thread for this discussion since these choices are orthogonal to what we are confirming with this vote: that we will use major version for incompatible changes. > What are the criteria for closing a major format version? I think that the vote would be decided by consensus, not a majority. On Mon, Jul 6, 2026 at 10:21 PM Micah Kornfield <[email protected]> wrote: > -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 > > >
