Hey Ryan, Where do forward-compatible changes live in the proposed model?
Say, we're at v1.0 right now, and a non-breaking change gets added. Which version of the format represents that? I don't think it can be v1.0, as that has shipped and its feature set should be fixed (or not?). But it's not v2.0 either. So is it some implicit v1.0++? Fleshing out the proposal also in that regard would be useful. Best, --Gunnar On Wed, 8 Jul 2026 at 02:34, Micah Kornfield <[email protected]> wrote: > > Hi Ryan, > > > > 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? > > > I intended -1 initially because I read the vote as being prescriptive of > the process for both versioning and releases. If this vote is simply to > close out the "version > versus "preset" debate then I'm +1 on using versions as the primary way we > recommend writers group changes and a general baseline [1] for what we > recommend expect readers to support. Ryan, is this a correct > interpretation of what we are voting on? > > Given the rest of the thread and other responses, I think there is still > some amount of details to work through. As noted by my questions and > request for a more detailed PR proposal on concrete process changes. If > those are coming then great. If we are aligned on what this vote is about > above, from my perspective we can move into more depth into those > discussions. [2] is an example of how this could work, there might be > other alternatives. > > Antoine, given the scope of vote outlined above do you still have > reservations? > > 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 > > > A side thread was already started here: > https://lists.apache.org/thread/qc031s9vp07bpkrvlnz3v3gn0qhn5l91 > > Thanks, > Micah > > [1] This is specifically a general baseline because I think there are > several short-comings of relying on version number as gate for readers. > [2] https://github.com/apache/parquet-format/pull/588 > > > > On Tue, Jul 7, 2026 at 12:07 PM Ryan Blue <[email protected]> wrote: > > > +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 > > > > > > > > >
