> The previous thread was entitled "[DISCUSS] Moving to SemVer for > parquet-format releases". :-)
We should not conflate parquet-format releases with versions of the Parquet spec. Much of the spec is defined in the thrift file of that release, but it's not the same thing. What we have been discussing (in the "Future of Parquet Versioning") is how to group together and release forward-incompatible changes. This decision would no doubt affect the version numbers used by parquet-format, but the use of versions for incompatible changes has to be decided before going into detail about downstream snapshots of the spec. > That's a good point. It deserves encoding somewhere, IMHO. How about a vote? Once we decide, we can memorialize it in documentation. I know a guy who has Claude credits to burn. 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. > > >
