On the vote thread, Antoine asked: > Can you expand on which changes are blocked on this?
We want to remove `path_in_schema`, which means we need to understand how we are (safely) making breaking changes. This is also relevant to the design of vector types. What we've been discussing is having a logical type for a non-breaking change, but introducing a new repetition level or vector types. This is a forward-incompatible update to encoding and we want to know the constraints. For example, do we need to make some breaking change to the Thrift definition so that clients fail to deserialize? Or are we going to have a more standard way to signal clients that a file is not readable? > > If nothing else, I'm glad that this thread is resulting in more serious > > consideration and questions. > > Indeed, but then we agree this is not ready for a vote, right? No, but I think that we can leave the vote open for longer if you need more time. The scope of this vote is narrow: are we using versions and releasing them by a vote? That's pretty straightforward. I'm happy to clarify other aspects here for anyone that is interested. But it's important to move forward incrementally. The discussion had largely concluded and I think we understand what decision needs to be made. I'd even go further and say that we are quite close to consensus on versions being the choice. As I said to summarize the discussion: "I think there's more support for the version option and we have a clear direction. There are differing opinions about what would be _best_ but no one is arguing that versions will not work." I still don't see anyone arguing that versions would not work, and we have at least 2 examples of communities successfully using versions to manage format changes. On Thu, Jul 9, 2026 at 1:29 PM Antoine Pitrou <[email protected]> wrote: > > Le 09/07/2026 à 22:02, Ryan Blue a écrit : > >> Not quite, because as pointed in another thread, a major version change > >> in SemVer points to *backwards* incompatible changes, not forwards > >> incompatible changes. > > > > I would not confuse what is being proposed with SemVer. SemVer is for API > > compatibility and it doesn't directly translate to formats. Saying that > the > > spec or format follows SemVer would be a very different idea. > > The previous thread was entitled "[DISCUSS] Moving to SemVer for > parquet-format releases". :-) > > > In SemVer, a major version bump means my existing code might break > because > > an API was removed or modified. A minor version bump means that new APIs > > were added but existing code will continue to work. So: > > - Major version change: existing code may break (this number defines a > > compatibility level) > > - Other version changes: existing code should not break > > > > The definition for formats is similar: > > - Major version change: existing readers may break (this number defines a > > compatibility level) > > - Other changes: existing readers continue to read correctly > > > > We can decide if we want to have minor versions or patch versions, but > the > > core idea is the same. > > That's a good point. It deserves encoding somewhere, IMHO. > > Regards > > Antoine. > > >
