TLDR: I want us to clearly understand the decision space, which does not
seem to be the case here. Which is why my vote is -1 on deciding this
*now*. We need a design document that outlines the various options and
records the arguments for and against them.
Le 09/07/2026 à 01:01, Ryan Blue a écrit :
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.
If there are questions left to answer then this is not ready to vote on,
IMHO.
There is no rush, we should take the time to do things right.
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.
Not quite, because as pointed in another thread, a major version change
in SemVer points to *backwards* incompatible changes, not forwards
incompatible changes.
In other communities, a new major version of a file format can mean that
it's backwards incompatible. IIUC, a Zarr v3-only reader wouldn't be
able to read Zarr v2 datasets, because the metadata encoding has changed.
(see https://zarr-specs.readthedocs.io/en/latest/specs.html)
In Parquet-land, if we choose to bump the major version every time a new
encoding is added (a backwards-incompatible change), this means we don't
have a way to signal backwards-incompatible changes such as a new file
footer.
I'm not saying that Parquet shouldn't choose this scheme, but it's not
as obvious and widely-held as you're making it to be. For example we
could decide that forwards-incompatible changes are a minor version
bump, and backwards-incompatible changes a major version bump. Which is
actually closer to how SemVer works.
Regards
Antoine.
