I'll start a new thread to answer related questions like those from Gunnar and Antoine, so that the vote thread doesn't drift from the vote.
To answer Micah's question and ensure it is clear, this vote is to confirm the choice to use version numbers and not presets. I'd like to leave this vote open. While there are some details to decide, like how to number parquet-format Jars, I think the idea of how versions work is generally well understood. In fact, one of the benefits is aligning with widely-held expectations for what a major version change means. But what matters most is that this choice is understood well enough for us to make a decision between the options. I think that is certainly the case given that the discussion thread has been inactive, and support was mostly in favor of versions that are determined by a vote (not a mechanistic process). I also strongly disagree with characterizing this as a proof of concept. This has worked for the Iceberg community for the last 8 years, and we inherited it from Parquet in the first place. Ryan On Wed, Jul 8, 2026 at 2:38 AM Antoine Pitrou <[email protected]> wrote: > > If the vote description was ambiguous and prone to confusion, then a > better-formulated vote should be started instead of trying to bring > clarification and build consensus in the vote thread, IMHO. > > I also agree with Micah that there are still details to clarify, so a > vote sounds a bit prematurate to me. > > For example, what does "a community vote to close and adopt each major > version": is it about choosing when we freeze the version? or about > which pending features we decide to include in it? are we envisioning a > situation where we defer a feature to version N+1 for some reasons? > > (personally, I'd like to avoid creating a process where the set of > features in a Parquet format version is prone to negotiations between > stakeholders) > > Therefore, I'm -1 because this proposal looks more like a PoC at the > moment (sorry!). > > Regards > > Antoine. > > > > Le 08/07/2026 à 02:33, Micah Kornfield a écrit : > > 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 > >>>> > >>> > >> > > > > >
