You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@parquet.apache.org by Julien Le Dem <ju...@apache.org> on 2026/07/31 21:06:52 UTC

[VOTE] Use versions to release forward-incompatible changes (take 2)

Hello everyone,

Following questions on the the previous vote
<https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq> thread,
here is a new vote essentially proposing the same thing but clarifying the
specific points raised then. This is the result of our discussions over the
last two weeks. With the direction set, we'll work on the linked design to
finalize the implementation details. We decided to start a fresh vote to
remove ambiguity of clarifying while voting is happening. See below.

Julien

This vote is to formalize our intent to use major version numbers to bundle
groups of new features in Parquet. This is especially important to enable
the safe roll-out of forward incompatible features (examples: new
encodings). We will separately iron out the implementation details in
the Parquet
Versioning doc
<https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2>
based on the principles below.

Goals:

   -

   Have a clear definition of what is forward compatible or not.
   -

   Have a clear definition of what supporting a specific Parquet version
   means (for write and for read).
   -

   Have clear version numbers for the ecosystem to coordinate on what’s
   coming in the next version. Pragmatism will prevail by making them not too
   frequent but not too far apart.
   -

   Ensure new features become mainstream in a reasonable amount of time.


Specifically,

   -

   We will accumulate forward-incompatible changes targeted at the next
   major version of the Parquet spec (for example Version 3). These
are called “In
   preview”
   -

   The same bar applies as before (two implementations, cross-testing, …
   <https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format>)
   to add these features in preview in the spec.
   -

   While in preview they can be used for writing with a feature flag, in
   particular to allow integration testing. All implementations are encouraged
   to start being able to read it ASAP (at least two distinct OSS
   implementations are already required to reach this stage).
   -

   These new changes will automatically go into the next major version.
   (pragmatism applies for exceptions)
   -

   We will have a community vote to close and adopt the next major version.
   -

   At this point these features are no longer in preview. Systems
   supporting the new version of Parquet (example: Parquet V3) can start using
   it for writing new files by default. (Or communicate what they support
   reading and what they write into files).
   -

   In an environment that requires compatibility with at least one system
   that doesn’t support the latest version of Parquet yet, one can pin to a
   specific version by passing a dedicated option to the writer. (example,
   support reading Parquet V3 but opt to only write Parquet V2 until the
   environment has upgraded).


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 . . .

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Ryan Blue <bl...@apache.org>.
Late +1 from me as well.

On Tue, Aug 11, 2026 at 12:40 PM Fokko Driesprong <fo...@apache.org> wrote:

> Late +1 (binding)!
>
> Sorry for the late reply here, and thanks for driving this Julien!
>
> Kind regards,
> Fokko
>
> On 2026/08/10 22:19:33 Julien Le Dem wrote:
> > and my +1 (binding) here.
> >
> > With 5 binding +1s, 9 (non binding) +1s and no -1s, the vote passes.
> > Thank you all who participated.
> > Next, we'll work on finalizing the spec.
> >
> >
> > On Sun, Aug 9, 2026 at 8:16 PM Russell Spitzer <
> russell.spitzer@gmail.com>
> > wrote:
> >
> > > +1 non binding
> > >
> > > On Thu, Aug 6, 2026 at 12:03 AM Matt Topol <zo...@gmail.com>
> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > On Wed, Aug 5, 2026, 10:32 PM Amogh Jahagirdar <2a...@gmail.com>
> wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org>
> > > wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Excited to see this moving forward!
> > > > > >
> > > > > > On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <
> > > emkornfield@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <
> prtkgaur@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > +1 (non-binding).
> > > > > > > >
> > > > > > > > Thanks to everyone who helped move this proposal.
> > > > > > > >
> > > > > > > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org>
> > > > wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Thanks to all who helped move this forward.
> > > > > > > > >
> > > > > > > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > > > > > > +1 (binding)
> > > > > > > > > >
> > > > > > > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via
> dev <
> > > > > > > > > > > dev@parquet.apache.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Great work with the proposal. Time to start hashing
> out
> > > the
> > > > > > > > details!
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev
> <
> > > > > > > > > > > > dev@parquet.apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you Julien, Ryan, and everyone else involved
> for
> > > > > > pushing
> > > > > > > > this
> > > > > > > > > > > > > forward!
> > > > > > > > > > > > >
> > > > > > > > > > > > > — Div
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > > > > > > andrewlamb11@gmail.com
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +1
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I agree with Neelesh, I believe this will be a
> major
> > > > step
> > > > > > > > > forward for
> > > > > > > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > > > > > > neeleshssalian@gmail.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thank you for all the work that went into
> getting
> > > > this
> > > > > > to a
> > > > > > > > > good
> > > > > > > > > > > > place.
> > > > > > > > > > > > > > > This is a great next step for the community.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > > > > > > julien@apache.org
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > > > > > > <
> > > > > > > > > > >
> > > > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> > > > > > >
> > > > > > > > > > > > > > > thread,
> > > > > > > > > > > > > > > > here is a new vote essentially proposing the
> same
> > > > > thing
> > > > > > > but
> > > > > > > > > > > > > clarifying
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > specific points raised then. This is the
> result
> > > of
> > > > > our
> > > > > > > > > > > discussions
> > > > > > > > > > > > > over
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > last two weeks. With the direction set, we'll
> > > work
> > > > on
> > > > > > the
> > > > > > > > > linked
> > > > > > > > > > > > > design
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > finalize the implementation details. We
> decided
> > > to
> > > > > > start
> > > > > > > a
> > > > > > > > > fresh
> > > > > > > > > > > > vote
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > remove ambiguity of clarifying while voting
> is
> > > > > > happening.
> > > > > > > > See
> > > > > > > > > > > > below.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Julien
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This vote is to formalize our intent to use
> major
> > > > > > version
> > > > > > > > > numbers
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > bundle
> > > > > > > > > > > > > > > > groups of new features in Parquet. This is
> > > > especially
> > > > > > > > > important
> > > > > > > > > > > to
> > > > > > > > > > > > > > enable
> > > > > > > > > > > > > > > > the safe roll-out of forward incompatible
> > > features
> > > > > > > > > (examples: new
> > > > > > > > > > > > > > > > encodings). We will separately iron out the
> > > > > > > implementation
> > > > > > > > > > > details
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > > the Parquet
> > > > > > > > > > > > > > > > Versioning doc
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > based on the principles below.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Goals:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    Have a clear definition of what is forward
> > > > > > compatible
> > > > > > > or
> > > > > > > > > not.
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    Have a clear definition of what
> supporting a
> > > > > > specific
> > > > > > > > > Parquet
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    Have clear version numbers for the
> ecosystem
> > > to
> > > > > > > > > coordinate on
> > > > > > > > > > > > > what’s
> > > > > > > > > > > > > > > >    coming in the next version. Pragmatism
> will
> > > > > prevail
> > > > > > by
> > > > > > > > > making
> > > > > > > > > > > > them
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > too
> > > > > > > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    Ensure new features become mainstream in a
> > > > > > reasonable
> > > > > > > > > amount
> > > > > > > > > > > of
> > > > > > > > > > > > > > time.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Specifically,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    We will accumulate forward-incompatible
> > > changes
> > > > > > > targeted
> > > > > > > > > at
> > > > > > > > > > > the
> > > > > > > > > > > > > next
> > > > > > > > > > > > > > > >    major version of the Parquet spec (for
> example
> > > > > > Version
> > > > > > > > 3).
> > > > > > > > > > > These
> > > > > > > > > > > > > > > > are called “In
> > > > > > > > > > > > > > > >    preview”
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    The same bar applies as before (two
> > > > > implementations,
> > > > > > > > > > > > > cross-testing,
> > > > > > > > > > > > > > …
> > > > > > > > > > > > > > > >    <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > > > > > > >)
> > > > > > > > > > > > > > > >    to add these features in preview in the
> spec.
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    While in preview they can be used for
> writing
> > > > > with a
> > > > > > > > > feature
> > > > > > > > > > > > flag,
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > >    particular to allow integration testing.
> All
> > > > > > > > > implementations
> > > > > > > > > > > are
> > > > > > > > > > > > > > > > encouraged
> > > > > > > > > > > > > > > >    to start being able to read it ASAP (at
> least
> > > > two
> > > > > > > > > distinct OSS
> > > > > > > > > > > > > > > >    implementations are already required to
> reach
> > > > this
> > > > > > > > stage).
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    These new changes will automatically go
> into
> > > the
> > > > > > next
> > > > > > > > > major
> > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    We will have a community vote to close and
> > > adopt
> > > > > the
> > > > > > > > next
> > > > > > > > > > > major
> > > > > > > > > > > > > > > version.
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    At this point these features are no
> longer in
> > > > > > preview.
> > > > > > > > > Systems
> > > > > > > > > > > > > > > >    supporting the new version of Parquet
> > > (example:
> > > > > > > Parquet
> > > > > > > > > V3)
> > > > > > > > > > > can
> > > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > > >    it for writing new files by default. (Or
> > > > > communicate
> > > > > > > > what
> > > > > > > > > they
> > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >    In an environment that requires
> compatibility
> > > > with
> > > > > > at
> > > > > > > > > least
> > > > > > > > > > > one
> > > > > > > > > > > > > > system
> > > > > > > > > > > > > > > >    that doesn’t support the latest version of
> > > > Parquet
> > > > > > > yet,
> > > > > > > > > one
> > > > > > > > > > > can
> > > > > > > > > > > > > pin
> > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > >    specific version by passing a dedicated
> option
> > > > to
> > > > > > the
> > > > > > > > > writer.
> > > > > > > > > > > > > > > (example,
> > > > > > > > > > > > > > > >    support reading Parquet V3 but opt to only
> > > write
> > > > > > > Parquet
> > > > > > > > > V2
> > > > > > > > > > > > until
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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
> > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Fokko Driesprong <fo...@apache.org>.
Late +1 (binding)!

Sorry for the late reply here, and thanks for driving this Julien!

Kind regards,
Fokko

On 2026/08/10 22:19:33 Julien Le Dem wrote:
> and my +1 (binding) here.
> 
> With 5 binding +1s, 9 (non binding) +1s and no -1s, the vote passes.
> Thank you all who participated.
> Next, we'll work on finalizing the spec.
> 
> 
> On Sun, Aug 9, 2026 at 8:16 PM Russell Spitzer <ru...@gmail.com>
> wrote:
> 
> > +1 non binding
> >
> > On Thu, Aug 6, 2026 at 12:03 AM Matt Topol <zo...@gmail.com> wrote:
> >
> > > +1 (non-binding)
> > >
> > > On Wed, Aug 5, 2026, 10:32 PM Amogh Jahagirdar <2a...@gmail.com> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org>
> > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Excited to see this moving forward!
> > > > >
> > > > > On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <
> > emkornfield@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > +1 (non-binding).
> > > > > > >
> > > > > > > Thanks to everyone who helped move this proposal.
> > > > > > >
> > > > > > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Thanks to all who helped move this forward.
> > > > > > > >
> > > > > > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > > > > > +1 (binding)
> > > > > > > > >
> > > > > > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > > +1
> > > > > > > > > >
> > > > > > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > > > > > > dev@parquet.apache.org> wrote:
> > > > > > > > > >
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Great work with the proposal. Time to start hashing out
> > the
> > > > > > > details!
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > > > > > > dev@parquet.apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you Julien, Ryan, and everyone else involved for
> > > > > pushing
> > > > > > > this
> > > > > > > > > > > > forward!
> > > > > > > > > > > >
> > > > > > > > > > > > — Div
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > > > > > andrewlamb11@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > +1
> > > > > > > > > > > > >
> > > > > > > > > > > > > I agree with Neelesh, I believe this will be a major
> > > step
> > > > > > > > forward for
> > > > > > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > > > > > neeleshssalian@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thank you for all the work that went into getting
> > > this
> > > > > to a
> > > > > > > > good
> > > > > > > > > > > place.
> > > > > > > > > > > > > > This is a great next step for the community.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > > > > > julien@apache.org
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > > > > > <
> > > > > > > > > >
> > > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> > > > > >
> > > > > > > > > > > > > > thread,
> > > > > > > > > > > > > > > here is a new vote essentially proposing the same
> > > > thing
> > > > > > but
> > > > > > > > > > > > clarifying
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > specific points raised then. This is the result
> > of
> > > > our
> > > > > > > > > > discussions
> > > > > > > > > > > > over
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > last two weeks. With the direction set, we'll
> > work
> > > on
> > > > > the
> > > > > > > > linked
> > > > > > > > > > > > design
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > finalize the implementation details. We decided
> > to
> > > > > start
> > > > > > a
> > > > > > > > fresh
> > > > > > > > > > > vote
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > remove ambiguity of clarifying while voting is
> > > > > happening.
> > > > > > > See
> > > > > > > > > > > below.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Julien
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This vote is to formalize our intent to use major
> > > > > version
> > > > > > > > numbers
> > > > > > > > > > > to
> > > > > > > > > > > > > > bundle
> > > > > > > > > > > > > > > groups of new features in Parquet. This is
> > > especially
> > > > > > > > important
> > > > > > > > > > to
> > > > > > > > > > > > > enable
> > > > > > > > > > > > > > > the safe roll-out of forward incompatible
> > features
> > > > > > > > (examples: new
> > > > > > > > > > > > > > > encodings). We will separately iron out the
> > > > > > implementation
> > > > > > > > > > details
> > > > > > > > > > > in
> > > > > > > > > > > > > > > the Parquet
> > > > > > > > > > > > > > > Versioning doc
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > based on the principles below.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Goals:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    Have a clear definition of what is forward
> > > > > compatible
> > > > > > or
> > > > > > > > not.
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    Have a clear definition of what supporting a
> > > > > specific
> > > > > > > > Parquet
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    Have clear version numbers for the ecosystem
> > to
> > > > > > > > coordinate on
> > > > > > > > > > > > what’s
> > > > > > > > > > > > > > >    coming in the next version. Pragmatism will
> > > > prevail
> > > > > by
> > > > > > > > making
> > > > > > > > > > > them
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > too
> > > > > > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    Ensure new features become mainstream in a
> > > > > reasonable
> > > > > > > > amount
> > > > > > > > > > of
> > > > > > > > > > > > > time.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Specifically,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    We will accumulate forward-incompatible
> > changes
> > > > > > targeted
> > > > > > > > at
> > > > > > > > > > the
> > > > > > > > > > > > next
> > > > > > > > > > > > > > >    major version of the Parquet spec (for example
> > > > > Version
> > > > > > > 3).
> > > > > > > > > > These
> > > > > > > > > > > > > > > are called “In
> > > > > > > > > > > > > > >    preview”
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    The same bar applies as before (two
> > > > implementations,
> > > > > > > > > > > > cross-testing,
> > > > > > > > > > > > > …
> > > > > > > > > > > > > > >    <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > > > > > >)
> > > > > > > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    While in preview they can be used for writing
> > > > with a
> > > > > > > > feature
> > > > > > > > > > > flag,
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > >    particular to allow integration testing. All
> > > > > > > > implementations
> > > > > > > > > > are
> > > > > > > > > > > > > > > encouraged
> > > > > > > > > > > > > > >    to start being able to read it ASAP (at least
> > > two
> > > > > > > > distinct OSS
> > > > > > > > > > > > > > >    implementations are already required to reach
> > > this
> > > > > > > stage).
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    These new changes will automatically go into
> > the
> > > > > next
> > > > > > > > major
> > > > > > > > > > > > version.
> > > > > > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    We will have a community vote to close and
> > adopt
> > > > the
> > > > > > > next
> > > > > > > > > > major
> > > > > > > > > > > > > > version.
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    At this point these features are no longer in
> > > > > preview.
> > > > > > > > Systems
> > > > > > > > > > > > > > >    supporting the new version of Parquet
> > (example:
> > > > > > Parquet
> > > > > > > > V3)
> > > > > > > > > > can
> > > > > > > > > > > > > start
> > > > > > > > > > > > > > > using
> > > > > > > > > > > > > > >    it for writing new files by default. (Or
> > > > communicate
> > > > > > > what
> > > > > > > > they
> > > > > > > > > > > > > support
> > > > > > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > > > > > >    -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >    In an environment that requires compatibility
> > > with
> > > > > at
> > > > > > > > least
> > > > > > > > > > one
> > > > > > > > > > > > > system
> > > > > > > > > > > > > > >    that doesn’t support the latest version of
> > > Parquet
> > > > > > yet,
> > > > > > > > one
> > > > > > > > > > can
> > > > > > > > > > > > pin
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > >    specific version by passing a dedicated option
> > > to
> > > > > the
> > > > > > > > writer.
> > > > > > > > > > > > > > (example,
> > > > > > > > > > > > > > >    support reading Parquet V3 but opt to only
> > write
> > > > > > Parquet
> > > > > > > > V2
> > > > > > > > > > > until
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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
> > > > > > > > > > > > > .
> > > > > > > > > > > > > > .
> > > > > > > > > > > > > > > .
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Julien Le Dem <ju...@apache.org>.
and my +1 (binding) here.

With 5 binding +1s, 9 (non binding) +1s and no -1s, the vote passes.
Thank you all who participated.
Next, we'll work on finalizing the spec.


On Sun, Aug 9, 2026 at 8:16 PM Russell Spitzer <ru...@gmail.com>
wrote:

> +1 non binding
>
> On Thu, Aug 6, 2026 at 12:03 AM Matt Topol <zo...@gmail.com> wrote:
>
> > +1 (non-binding)
> >
> > On Wed, Aug 5, 2026, 10:32 PM Amogh Jahagirdar <2a...@gmail.com> wrote:
> >
> > > +1 (non-binding)
> > >
> > > On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org>
> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Excited to see this moving forward!
> > > >
> > > > On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <
> emkornfield@gmail.com>
> > > > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1 (non-binding).
> > > > > >
> > > > > > Thanks to everyone who helped move this proposal.
> > > > > >
> > > > > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org>
> > wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Thanks to all who helped move this forward.
> > > > > > >
> > > > > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > > > > +1 (binding)
> > > > > > > >
> > > > > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > > > > > dev@parquet.apache.org> wrote:
> > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Great work with the proposal. Time to start hashing out
> the
> > > > > > details!
> > > > > > > > > >
> > > > > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > > > > > dev@parquet.apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Thank you Julien, Ryan, and everyone else involved for
> > > > pushing
> > > > > > this
> > > > > > > > > > > forward!
> > > > > > > > > > >
> > > > > > > > > > > — Div
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > > > > andrewlamb11@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1
> > > > > > > > > > > >
> > > > > > > > > > > > I agree with Neelesh, I believe this will be a major
> > step
> > > > > > > forward for
> > > > > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > > > > neeleshssalian@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you for all the work that went into getting
> > this
> > > > to a
> > > > > > > good
> > > > > > > > > > place.
> > > > > > > > > > > > > This is a great next step for the community.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > > > > julien@apache.org
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > > > > <
> > > > > > > > >
> > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> > > > >
> > > > > > > > > > > > > thread,
> > > > > > > > > > > > > > here is a new vote essentially proposing the same
> > > thing
> > > > > but
> > > > > > > > > > > clarifying
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > specific points raised then. This is the result
> of
> > > our
> > > > > > > > > discussions
> > > > > > > > > > > over
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > last two weeks. With the direction set, we'll
> work
> > on
> > > > the
> > > > > > > linked
> > > > > > > > > > > design
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > finalize the implementation details. We decided
> to
> > > > start
> > > > > a
> > > > > > > fresh
> > > > > > > > > > vote
> > > > > > > > > > > > to
> > > > > > > > > > > > > > remove ambiguity of clarifying while voting is
> > > > happening.
> > > > > > See
> > > > > > > > > > below.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Julien
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This vote is to formalize our intent to use major
> > > > version
> > > > > > > numbers
> > > > > > > > > > to
> > > > > > > > > > > > > bundle
> > > > > > > > > > > > > > groups of new features in Parquet. This is
> > especially
> > > > > > > important
> > > > > > > > > to
> > > > > > > > > > > > enable
> > > > > > > > > > > > > > the safe roll-out of forward incompatible
> features
> > > > > > > (examples: new
> > > > > > > > > > > > > > encodings). We will separately iron out the
> > > > > implementation
> > > > > > > > > details
> > > > > > > > > > in
> > > > > > > > > > > > > > the Parquet
> > > > > > > > > > > > > > Versioning doc
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > based on the principles below.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Goals:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    Have a clear definition of what is forward
> > > > compatible
> > > > > or
> > > > > > > not.
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    Have a clear definition of what supporting a
> > > > specific
> > > > > > > Parquet
> > > > > > > > > > > > version
> > > > > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    Have clear version numbers for the ecosystem
> to
> > > > > > > coordinate on
> > > > > > > > > > > what’s
> > > > > > > > > > > > > >    coming in the next version. Pragmatism will
> > > prevail
> > > > by
> > > > > > > making
> > > > > > > > > > them
> > > > > > > > > > > > not
> > > > > > > > > > > > > > too
> > > > > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    Ensure new features become mainstream in a
> > > > reasonable
> > > > > > > amount
> > > > > > > > > of
> > > > > > > > > > > > time.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Specifically,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    We will accumulate forward-incompatible
> changes
> > > > > targeted
> > > > > > > at
> > > > > > > > > the
> > > > > > > > > > > next
> > > > > > > > > > > > > >    major version of the Parquet spec (for example
> > > > Version
> > > > > > 3).
> > > > > > > > > These
> > > > > > > > > > > > > > are called “In
> > > > > > > > > > > > > >    preview”
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    The same bar applies as before (two
> > > implementations,
> > > > > > > > > > > cross-testing,
> > > > > > > > > > > > …
> > > > > > > > > > > > > >    <
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > > > > >)
> > > > > > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    While in preview they can be used for writing
> > > with a
> > > > > > > feature
> > > > > > > > > > flag,
> > > > > > > > > > > > in
> > > > > > > > > > > > > >    particular to allow integration testing. All
> > > > > > > implementations
> > > > > > > > > are
> > > > > > > > > > > > > > encouraged
> > > > > > > > > > > > > >    to start being able to read it ASAP (at least
> > two
> > > > > > > distinct OSS
> > > > > > > > > > > > > >    implementations are already required to reach
> > this
> > > > > > stage).
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    These new changes will automatically go into
> the
> > > > next
> > > > > > > major
> > > > > > > > > > > version.
> > > > > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    We will have a community vote to close and
> adopt
> > > the
> > > > > > next
> > > > > > > > > major
> > > > > > > > > > > > > version.
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    At this point these features are no longer in
> > > > preview.
> > > > > > > Systems
> > > > > > > > > > > > > >    supporting the new version of Parquet
> (example:
> > > > > Parquet
> > > > > > > V3)
> > > > > > > > > can
> > > > > > > > > > > > start
> > > > > > > > > > > > > > using
> > > > > > > > > > > > > >    it for writing new files by default. (Or
> > > communicate
> > > > > > what
> > > > > > > they
> > > > > > > > > > > > support
> > > > > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > > > > >    -
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    In an environment that requires compatibility
> > with
> > > > at
> > > > > > > least
> > > > > > > > > one
> > > > > > > > > > > > system
> > > > > > > > > > > > > >    that doesn’t support the latest version of
> > Parquet
> > > > > yet,
> > > > > > > one
> > > > > > > > > can
> > > > > > > > > > > pin
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > >    specific version by passing a dedicated option
> > to
> > > > the
> > > > > > > writer.
> > > > > > > > > > > > > (example,
> > > > > > > > > > > > > >    support reading Parquet V3 but opt to only
> write
> > > > > Parquet
> > > > > > > V2
> > > > > > > > > > until
> > > > > > > > > > > > the
> > > > > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> > > > > > > > > > > > .
> > > > > > > > > > > > > .
> > > > > > > > > > > > > > .
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Russell Spitzer <ru...@gmail.com>.
+1 non binding

On Thu, Aug 6, 2026 at 12:03 AM Matt Topol <zo...@gmail.com> wrote:

> +1 (non-binding)
>
> On Wed, Aug 5, 2026, 10:32 PM Amogh Jahagirdar <2a...@gmail.com> wrote:
>
> > +1 (non-binding)
> >
> > On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Excited to see this moving forward!
> > >
> > > On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <em...@gmail.com>
> > > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com>
> > wrote:
> > > >
> > > > > +1 (non-binding).
> > > > >
> > > > > Thanks to everyone who helped move this proposal.
> > > > >
> > > > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org>
> wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Thanks to all who helped move this forward.
> > > > > >
> > > > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > > > > dev@parquet.apache.org> wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Great work with the proposal. Time to start hashing out the
> > > > > details!
> > > > > > > > >
> > > > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > > > > dev@parquet.apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Thank you Julien, Ryan, and everyone else involved for
> > > pushing
> > > > > this
> > > > > > > > > > forward!
> > > > > > > > > >
> > > > > > > > > > — Div
> > > > > > > > > >
> > > > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > > > andrewlamb11@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1
> > > > > > > > > > >
> > > > > > > > > > > I agree with Neelesh, I believe this will be a major
> step
> > > > > > forward for
> > > > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > > > neeleshssalian@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for all the work that went into getting
> this
> > > to a
> > > > > > good
> > > > > > > > > place.
> > > > > > > > > > > > This is a great next step for the community.
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > > > julien@apache.org
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > > > <
> > > > > > > >
> > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> > > >
> > > > > > > > > > > > thread,
> > > > > > > > > > > > > here is a new vote essentially proposing the same
> > thing
> > > > but
> > > > > > > > > > clarifying
> > > > > > > > > > > > the
> > > > > > > > > > > > > specific points raised then. This is the result of
> > our
> > > > > > > > discussions
> > > > > > > > > > over
> > > > > > > > > > > > the
> > > > > > > > > > > > > last two weeks. With the direction set, we'll work
> on
> > > the
> > > > > > linked
> > > > > > > > > > design
> > > > > > > > > > > > to
> > > > > > > > > > > > > finalize the implementation details. We decided to
> > > start
> > > > a
> > > > > > fresh
> > > > > > > > > vote
> > > > > > > > > > > to
> > > > > > > > > > > > > remove ambiguity of clarifying while voting is
> > > happening.
> > > > > See
> > > > > > > > > below.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Julien
> > > > > > > > > > > > >
> > > > > > > > > > > > > This vote is to formalize our intent to use major
> > > version
> > > > > > numbers
> > > > > > > > > to
> > > > > > > > > > > > bundle
> > > > > > > > > > > > > groups of new features in Parquet. This is
> especially
> > > > > > important
> > > > > > > > to
> > > > > > > > > > > enable
> > > > > > > > > > > > > the safe roll-out of forward incompatible features
> > > > > > (examples: new
> > > > > > > > > > > > > encodings). We will separately iron out the
> > > > implementation
> > > > > > > > details
> > > > > > > > > in
> > > > > > > > > > > > > the Parquet
> > > > > > > > > > > > > Versioning doc
> > > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > > > >
> > > > > > > > > > > > > based on the principles below.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Goals:
> > > > > > > > > > > > >
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    Have a clear definition of what is forward
> > > compatible
> > > > or
> > > > > > not.
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    Have a clear definition of what supporting a
> > > specific
> > > > > > Parquet
> > > > > > > > > > > version
> > > > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    Have clear version numbers for the ecosystem to
> > > > > > coordinate on
> > > > > > > > > > what’s
> > > > > > > > > > > > >    coming in the next version. Pragmatism will
> > prevail
> > > by
> > > > > > making
> > > > > > > > > them
> > > > > > > > > > > not
> > > > > > > > > > > > > too
> > > > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    Ensure new features become mainstream in a
> > > reasonable
> > > > > > amount
> > > > > > > > of
> > > > > > > > > > > time.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Specifically,
> > > > > > > > > > > > >
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    We will accumulate forward-incompatible changes
> > > > targeted
> > > > > > at
> > > > > > > > the
> > > > > > > > > > next
> > > > > > > > > > > > >    major version of the Parquet spec (for example
> > > Version
> > > > > 3).
> > > > > > > > These
> > > > > > > > > > > > > are called “In
> > > > > > > > > > > > >    preview”
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    The same bar applies as before (two
> > implementations,
> > > > > > > > > > cross-testing,
> > > > > > > > > > > …
> > > > > > > > > > > > >    <
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > > > >)
> > > > > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    While in preview they can be used for writing
> > with a
> > > > > > feature
> > > > > > > > > flag,
> > > > > > > > > > > in
> > > > > > > > > > > > >    particular to allow integration testing. All
> > > > > > implementations
> > > > > > > > are
> > > > > > > > > > > > > encouraged
> > > > > > > > > > > > >    to start being able to read it ASAP (at least
> two
> > > > > > distinct OSS
> > > > > > > > > > > > >    implementations are already required to reach
> this
> > > > > stage).
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    These new changes will automatically go into the
> > > next
> > > > > > major
> > > > > > > > > > version.
> > > > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    We will have a community vote to close and adopt
> > the
> > > > > next
> > > > > > > > major
> > > > > > > > > > > > version.
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    At this point these features are no longer in
> > > preview.
> > > > > > Systems
> > > > > > > > > > > > >    supporting the new version of Parquet (example:
> > > > Parquet
> > > > > > V3)
> > > > > > > > can
> > > > > > > > > > > start
> > > > > > > > > > > > > using
> > > > > > > > > > > > >    it for writing new files by default. (Or
> > communicate
> > > > > what
> > > > > > they
> > > > > > > > > > > support
> > > > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > > > >    -
> > > > > > > > > > > > >
> > > > > > > > > > > > >    In an environment that requires compatibility
> with
> > > at
> > > > > > least
> > > > > > > > one
> > > > > > > > > > > system
> > > > > > > > > > > > >    that doesn’t support the latest version of
> Parquet
> > > > yet,
> > > > > > one
> > > > > > > > can
> > > > > > > > > > pin
> > > > > > > > > > > > to a
> > > > > > > > > > > > >    specific version by passing a dedicated option
> to
> > > the
> > > > > > writer.
> > > > > > > > > > > > (example,
> > > > > > > > > > > > >    support reading Parquet V3 but opt to only write
> > > > Parquet
> > > > > > V2
> > > > > > > > > until
> > > > > > > > > > > the
> > > > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > > > .
> > > > > > > > > > > > .
> > > > > > > > > > > > > .
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Matt Topol <zo...@gmail.com>.
+1 (non-binding)

On Wed, Aug 5, 2026, 10:32 PM Amogh Jahagirdar <2a...@gmail.com> wrote:

> +1 (non-binding)
>
> On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org> wrote:
>
> > +1 (non-binding)
> >
> > Excited to see this moving forward!
> >
> > On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <em...@gmail.com>
> > wrote:
> >
> > > +1 (binding)
> > >
> > > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com>
> wrote:
> > >
> > > > +1 (non-binding).
> > > >
> > > > Thanks to everyone who helped move this proposal.
> > > >
> > > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org> wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Thanks to all who helped move this forward.
> > > > >
> > > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > > +1 (binding)
> > > > > >
> > > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > > > dev@parquet.apache.org> wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Great work with the proposal. Time to start hashing out the
> > > > details!
> > > > > > > >
> > > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > > > dev@parquet.apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Thank you Julien, Ryan, and everyone else involved for
> > pushing
> > > > this
> > > > > > > > > forward!
> > > > > > > > >
> > > > > > > > > — Div
> > > > > > > > >
> > > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > > andrewlamb11@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1
> > > > > > > > > >
> > > > > > > > > > I agree with Neelesh, I believe this will be a major step
> > > > > forward for
> > > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > > >
> > > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > > neeleshssalian@gmail.com
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Thank you for all the work that went into getting this
> > to a
> > > > > good
> > > > > > > > place.
> > > > > > > > > > > This is a great next step for the community.
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > > julien@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > >
> > > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > > <
> > > > > > >
> https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> > >
> > > > > > > > > > > thread,
> > > > > > > > > > > > here is a new vote essentially proposing the same
> thing
> > > but
> > > > > > > > > clarifying
> > > > > > > > > > > the
> > > > > > > > > > > > specific points raised then. This is the result of
> our
> > > > > > > discussions
> > > > > > > > > over
> > > > > > > > > > > the
> > > > > > > > > > > > last two weeks. With the direction set, we'll work on
> > the
> > > > > linked
> > > > > > > > > design
> > > > > > > > > > > to
> > > > > > > > > > > > finalize the implementation details. We decided to
> > start
> > > a
> > > > > fresh
> > > > > > > > vote
> > > > > > > > > > to
> > > > > > > > > > > > remove ambiguity of clarifying while voting is
> > happening.
> > > > See
> > > > > > > > below.
> > > > > > > > > > > >
> > > > > > > > > > > > Julien
> > > > > > > > > > > >
> > > > > > > > > > > > This vote is to formalize our intent to use major
> > version
> > > > > numbers
> > > > > > > > to
> > > > > > > > > > > bundle
> > > > > > > > > > > > groups of new features in Parquet. This is especially
> > > > > important
> > > > > > > to
> > > > > > > > > > enable
> > > > > > > > > > > > the safe roll-out of forward incompatible features
> > > > > (examples: new
> > > > > > > > > > > > encodings). We will separately iron out the
> > > implementation
> > > > > > > details
> > > > > > > > in
> > > > > > > > > > > > the Parquet
> > > > > > > > > > > > Versioning doc
> > > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > > >
> > > > > > > > > > > > based on the principles below.
> > > > > > > > > > > >
> > > > > > > > > > > > Goals:
> > > > > > > > > > > >
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    Have a clear definition of what is forward
> > compatible
> > > or
> > > > > not.
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    Have a clear definition of what supporting a
> > specific
> > > > > Parquet
> > > > > > > > > > version
> > > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    Have clear version numbers for the ecosystem to
> > > > > coordinate on
> > > > > > > > > what’s
> > > > > > > > > > > >    coming in the next version. Pragmatism will
> prevail
> > by
> > > > > making
> > > > > > > > them
> > > > > > > > > > not
> > > > > > > > > > > > too
> > > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    Ensure new features become mainstream in a
> > reasonable
> > > > > amount
> > > > > > > of
> > > > > > > > > > time.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Specifically,
> > > > > > > > > > > >
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    We will accumulate forward-incompatible changes
> > > targeted
> > > > > at
> > > > > > > the
> > > > > > > > > next
> > > > > > > > > > > >    major version of the Parquet spec (for example
> > Version
> > > > 3).
> > > > > > > These
> > > > > > > > > > > > are called “In
> > > > > > > > > > > >    preview”
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    The same bar applies as before (two
> implementations,
> > > > > > > > > cross-testing,
> > > > > > > > > > …
> > > > > > > > > > > >    <
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > > >)
> > > > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    While in preview they can be used for writing
> with a
> > > > > feature
> > > > > > > > flag,
> > > > > > > > > > in
> > > > > > > > > > > >    particular to allow integration testing. All
> > > > > implementations
> > > > > > > are
> > > > > > > > > > > > encouraged
> > > > > > > > > > > >    to start being able to read it ASAP (at least two
> > > > > distinct OSS
> > > > > > > > > > > >    implementations are already required to reach this
> > > > stage).
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    These new changes will automatically go into the
> > next
> > > > > major
> > > > > > > > > version.
> > > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    We will have a community vote to close and adopt
> the
> > > > next
> > > > > > > major
> > > > > > > > > > > version.
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    At this point these features are no longer in
> > preview.
> > > > > Systems
> > > > > > > > > > > >    supporting the new version of Parquet (example:
> > > Parquet
> > > > > V3)
> > > > > > > can
> > > > > > > > > > start
> > > > > > > > > > > > using
> > > > > > > > > > > >    it for writing new files by default. (Or
> communicate
> > > > what
> > > > > they
> > > > > > > > > > support
> > > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > > >    -
> > > > > > > > > > > >
> > > > > > > > > > > >    In an environment that requires compatibility with
> > at
> > > > > least
> > > > > > > one
> > > > > > > > > > system
> > > > > > > > > > > >    that doesn’t support the latest version of Parquet
> > > yet,
> > > > > one
> > > > > > > can
> > > > > > > > > pin
> > > > > > > > > > > to a
> > > > > > > > > > > >    specific version by passing a dedicated option to
> > the
> > > > > writer.
> > > > > > > > > > > (example,
> > > > > > > > > > > >    support reading Parquet V3 but opt to only write
> > > Parquet
> > > > > V2
> > > > > > > > until
> > > > > > > > > > the
> > > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > > > .
> > > > > > > > > > > .
> > > > > > > > > > > > .
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Amogh Jahagirdar <2a...@gmail.com>.
+1 (non-binding)

On Wed, Aug 5, 2026 at 10:31 AM Kevin Liu <ke...@apache.org> wrote:

> +1 (non-binding)
>
> Excited to see this moving forward!
>
> On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <em...@gmail.com>
> wrote:
>
> > +1 (binding)
> >
> > On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com> wrote:
> >
> > > +1 (non-binding).
> > >
> > > Thanks to everyone who helped move this proposal.
> > >
> > > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Thanks to all who helped move this forward.
> > > >
> > > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > > +1 (binding)
> > > > >
> > > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > > dev@parquet.apache.org> wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Great work with the proposal. Time to start hashing out the
> > > details!
> > > > > > >
> > > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > > dev@parquet.apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Thank you Julien, Ryan, and everyone else involved for
> pushing
> > > this
> > > > > > > > forward!
> > > > > > > >
> > > > > > > > — Div
> > > > > > > >
> > > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> > andrewlamb11@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > I agree with Neelesh, I believe this will be a major step
> > > > forward for
> > > > > > > > > communicating compatibility across the ecosystem
> > > > > > > > >
> > > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > > neeleshssalian@gmail.com
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Thank you for all the work that went into getting this
> to a
> > > > good
> > > > > > > place.
> > > > > > > > > > This is a great next step for the community.
> > > > > > > > > >
> > > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > > julien@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello everyone,
> > > > > > > > > > >
> > > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > > <
> > > > > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq
> >
> > > > > > > > > > thread,
> > > > > > > > > > > here is a new vote essentially proposing the same thing
> > but
> > > > > > > > clarifying
> > > > > > > > > > the
> > > > > > > > > > > specific points raised then. This is the result of our
> > > > > > discussions
> > > > > > > > over
> > > > > > > > > > the
> > > > > > > > > > > last two weeks. With the direction set, we'll work on
> the
> > > > linked
> > > > > > > > design
> > > > > > > > > > to
> > > > > > > > > > > finalize the implementation details. We decided to
> start
> > a
> > > > fresh
> > > > > > > vote
> > > > > > > > > to
> > > > > > > > > > > remove ambiguity of clarifying while voting is
> happening.
> > > See
> > > > > > > below.
> > > > > > > > > > >
> > > > > > > > > > > Julien
> > > > > > > > > > >
> > > > > > > > > > > This vote is to formalize our intent to use major
> version
> > > > numbers
> > > > > > > to
> > > > > > > > > > bundle
> > > > > > > > > > > groups of new features in Parquet. This is especially
> > > > important
> > > > > > to
> > > > > > > > > enable
> > > > > > > > > > > the safe roll-out of forward incompatible features
> > > > (examples: new
> > > > > > > > > > > encodings). We will separately iron out the
> > implementation
> > > > > > details
> > > > > > > in
> > > > > > > > > > > the Parquet
> > > > > > > > > > > Versioning doc
> > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > > >
> > > > > > > > > > > based on the principles below.
> > > > > > > > > > >
> > > > > > > > > > > Goals:
> > > > > > > > > > >
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    Have a clear definition of what is forward
> compatible
> > or
> > > > not.
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    Have a clear definition of what supporting a
> specific
> > > > Parquet
> > > > > > > > > version
> > > > > > > > > > >    means (for write and for read).
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    Have clear version numbers for the ecosystem to
> > > > coordinate on
> > > > > > > > what’s
> > > > > > > > > > >    coming in the next version. Pragmatism will prevail
> by
> > > > making
> > > > > > > them
> > > > > > > > > not
> > > > > > > > > > > too
> > > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    Ensure new features become mainstream in a
> reasonable
> > > > amount
> > > > > > of
> > > > > > > > > time.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Specifically,
> > > > > > > > > > >
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    We will accumulate forward-incompatible changes
> > targeted
> > > > at
> > > > > > the
> > > > > > > > next
> > > > > > > > > > >    major version of the Parquet spec (for example
> Version
> > > 3).
> > > > > > These
> > > > > > > > > > > are called “In
> > > > > > > > > > >    preview”
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    The same bar applies as before (two implementations,
> > > > > > > > cross-testing,
> > > > > > > > > …
> > > > > > > > > > >    <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > > >)
> > > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    While in preview they can be used for writing with a
> > > > feature
> > > > > > > flag,
> > > > > > > > > in
> > > > > > > > > > >    particular to allow integration testing. All
> > > > implementations
> > > > > > are
> > > > > > > > > > > encouraged
> > > > > > > > > > >    to start being able to read it ASAP (at least two
> > > > distinct OSS
> > > > > > > > > > >    implementations are already required to reach this
> > > stage).
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    These new changes will automatically go into the
> next
> > > > major
> > > > > > > > version.
> > > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    We will have a community vote to close and adopt the
> > > next
> > > > > > major
> > > > > > > > > > version.
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    At this point these features are no longer in
> preview.
> > > > Systems
> > > > > > > > > > >    supporting the new version of Parquet (example:
> > Parquet
> > > > V3)
> > > > > > can
> > > > > > > > > start
> > > > > > > > > > > using
> > > > > > > > > > >    it for writing new files by default. (Or communicate
> > > what
> > > > they
> > > > > > > > > support
> > > > > > > > > > >    reading and what they write into files).
> > > > > > > > > > >    -
> > > > > > > > > > >
> > > > > > > > > > >    In an environment that requires compatibility with
> at
> > > > least
> > > > > > one
> > > > > > > > > system
> > > > > > > > > > >    that doesn’t support the latest version of Parquet
> > yet,
> > > > one
> > > > > > can
> > > > > > > > pin
> > > > > > > > > > to a
> > > > > > > > > > >    specific version by passing a dedicated option to
> the
> > > > writer.
> > > > > > > > > > (example,
> > > > > > > > > > >    support reading Parquet V3 but opt to only write
> > Parquet
> > > > V2
> > > > > > > until
> > > > > > > > > the
> > > > > > > > > > >    environment has upgraded).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > > > .
> > > > > > > > > > .
> > > > > > > > > > > .
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Kevin Liu <ke...@apache.org>.
+1 (non-binding)

Excited to see this moving forward!

On Wed, Aug 5, 2026 at 8:42 AM Micah Kornfield <em...@gmail.com>
wrote:

> +1 (binding)
>
> On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com> wrote:
>
> > +1 (non-binding).
> >
> > Thanks to everyone who helped move this proposal.
> >
> > On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Thanks to all who helped move this forward.
> > >
> > > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > > +1 (binding)
> > > >
> > > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > > dev@parquet.apache.org> wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Great work with the proposal. Time to start hashing out the
> > details!
> > > > > >
> > > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > > dev@parquet.apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Thank you Julien, Ryan, and everyone else involved for pushing
> > this
> > > > > > > forward!
> > > > > > >
> > > > > > > — Div
> > > > > > >
> > > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <
> andrewlamb11@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > I agree with Neelesh, I believe this will be a major step
> > > forward for
> > > > > > > > communicating compatibility across the ecosystem
> > > > > > > >
> > > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > > neeleshssalian@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Thank you for all the work that went into getting this to a
> > > good
> > > > > > place.
> > > > > > > > > This is a great next step for the community.
> > > > > > > > >
> > > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> > julien@apache.org
> > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello everyone,
> > > > > > > > > >
> > > > > > > > > > Following questions on the the previous vote
> > > > > > > > > > <
> > > > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > > > > > > thread,
> > > > > > > > > > here is a new vote essentially proposing the same thing
> but
> > > > > > > clarifying
> > > > > > > > > the
> > > > > > > > > > specific points raised then. This is the result of our
> > > > > discussions
> > > > > > > over
> > > > > > > > > the
> > > > > > > > > > last two weeks. With the direction set, we'll work on the
> > > linked
> > > > > > > design
> > > > > > > > > to
> > > > > > > > > > finalize the implementation details. We decided to start
> a
> > > fresh
> > > > > > vote
> > > > > > > > to
> > > > > > > > > > remove ambiguity of clarifying while voting is happening.
> > See
> > > > > > below.
> > > > > > > > > >
> > > > > > > > > > Julien
> > > > > > > > > >
> > > > > > > > > > This vote is to formalize our intent to use major version
> > > numbers
> > > > > > to
> > > > > > > > > bundle
> > > > > > > > > > groups of new features in Parquet. This is especially
> > > important
> > > > > to
> > > > > > > > enable
> > > > > > > > > > the safe roll-out of forward incompatible features
> > > (examples: new
> > > > > > > > > > encodings). We will separately iron out the
> implementation
> > > > > details
> > > > > > in
> > > > > > > > > > the Parquet
> > > > > > > > > > Versioning doc
> > > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > > >
> > > > > > > > > > based on the principles below.
> > > > > > > > > >
> > > > > > > > > > Goals:
> > > > > > > > > >
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    Have a clear definition of what is forward compatible
> or
> > > not.
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    Have a clear definition of what supporting a specific
> > > Parquet
> > > > > > > > version
> > > > > > > > > >    means (for write and for read).
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    Have clear version numbers for the ecosystem to
> > > coordinate on
> > > > > > > what’s
> > > > > > > > > >    coming in the next version. Pragmatism will prevail by
> > > making
> > > > > > them
> > > > > > > > not
> > > > > > > > > > too
> > > > > > > > > >    frequent but not too far apart.
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    Ensure new features become mainstream in a reasonable
> > > amount
> > > > > of
> > > > > > > > time.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Specifically,
> > > > > > > > > >
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    We will accumulate forward-incompatible changes
> targeted
> > > at
> > > > > the
> > > > > > > next
> > > > > > > > > >    major version of the Parquet spec (for example Version
> > 3).
> > > > > These
> > > > > > > > > > are called “In
> > > > > > > > > >    preview”
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    The same bar applies as before (two implementations,
> > > > > > > cross-testing,
> > > > > > > > …
> > > > > > > > > >    <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > > >)
> > > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    While in preview they can be used for writing with a
> > > feature
> > > > > > flag,
> > > > > > > > in
> > > > > > > > > >    particular to allow integration testing. All
> > > implementations
> > > > > are
> > > > > > > > > > encouraged
> > > > > > > > > >    to start being able to read it ASAP (at least two
> > > distinct OSS
> > > > > > > > > >    implementations are already required to reach this
> > stage).
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    These new changes will automatically go into the next
> > > major
> > > > > > > version.
> > > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    We will have a community vote to close and adopt the
> > next
> > > > > major
> > > > > > > > > version.
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    At this point these features are no longer in preview.
> > > Systems
> > > > > > > > > >    supporting the new version of Parquet (example:
> Parquet
> > > V3)
> > > > > can
> > > > > > > > start
> > > > > > > > > > using
> > > > > > > > > >    it for writing new files by default. (Or communicate
> > what
> > > they
> > > > > > > > support
> > > > > > > > > >    reading and what they write into files).
> > > > > > > > > >    -
> > > > > > > > > >
> > > > > > > > > >    In an environment that requires compatibility with at
> > > least
> > > > > one
> > > > > > > > system
> > > > > > > > > >    that doesn’t support the latest version of Parquet
> yet,
> > > one
> > > > > can
> > > > > > > pin
> > > > > > > > > to a
> > > > > > > > > >    specific version by passing a dedicated option to the
> > > writer.
> > > > > > > > > (example,
> > > > > > > > > >    support reading Parquet V3 but opt to only write
> Parquet
> > > V2
> > > > > > until
> > > > > > > > the
> > > > > > > > > >    environment has upgraded).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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
> > > > > > > > .
> > > > > > > > > .
> > > > > > > > > > .
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Micah Kornfield <em...@gmail.com>.
+1 (binding)

On Tue, Aug 4, 2026 at 10:22 PM PRATEEK GAUR <pr...@gmail.com> wrote:

> +1 (non-binding).
>
> Thanks to everyone who helped move this proposal.
>
> On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org> wrote:
>
> > +1 (non-binding)
> >
> > Thanks to all who helped move this forward.
> >
> > On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > > +1 (binding)
> > >
> > > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > > dev@parquet.apache.org> wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Great work with the proposal. Time to start hashing out the
> details!
> > > > >
> > > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > > dev@parquet.apache.org>
> > > > > wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Thank you Julien, Ryan, and everyone else involved for pushing
> this
> > > > > > forward!
> > > > > >
> > > > > > — Div
> > > > > >
> > > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <andrewlamb11@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > I agree with Neelesh, I believe this will be a major step
> > forward for
> > > > > > > communicating compatibility across the ecosystem
> > > > > > >
> > > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > > neeleshssalian@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Thank you for all the work that went into getting this to a
> > good
> > > > > place.
> > > > > > > > This is a great next step for the community.
> > > > > > > >
> > > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <
> julien@apache.org
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello everyone,
> > > > > > > > >
> > > > > > > > > Following questions on the the previous vote
> > > > > > > > > <
> > > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > > > > > thread,
> > > > > > > > > here is a new vote essentially proposing the same thing but
> > > > > > clarifying
> > > > > > > > the
> > > > > > > > > specific points raised then. This is the result of our
> > > > discussions
> > > > > > over
> > > > > > > > the
> > > > > > > > > last two weeks. With the direction set, we'll work on the
> > linked
> > > > > > design
> > > > > > > > to
> > > > > > > > > finalize the implementation details. We decided to start a
> > fresh
> > > > > vote
> > > > > > > to
> > > > > > > > > remove ambiguity of clarifying while voting is happening.
> See
> > > > > below.
> > > > > > > > >
> > > > > > > > > Julien
> > > > > > > > >
> > > > > > > > > This vote is to formalize our intent to use major version
> > numbers
> > > > > to
> > > > > > > > bundle
> > > > > > > > > groups of new features in Parquet. This is especially
> > important
> > > > to
> > > > > > > enable
> > > > > > > > > the safe roll-out of forward incompatible features
> > (examples: new
> > > > > > > > > encodings). We will separately iron out the implementation
> > > > details
> > > > > in
> > > > > > > > > the Parquet
> > > > > > > > > Versioning doc
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > > >
> > > > > > > > > based on the principles below.
> > > > > > > > >
> > > > > > > > > Goals:
> > > > > > > > >
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    Have a clear definition of what is forward compatible or
> > not.
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    Have a clear definition of what supporting a specific
> > Parquet
> > > > > > > version
> > > > > > > > >    means (for write and for read).
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    Have clear version numbers for the ecosystem to
> > coordinate on
> > > > > > what’s
> > > > > > > > >    coming in the next version. Pragmatism will prevail by
> > making
> > > > > them
> > > > > > > not
> > > > > > > > > too
> > > > > > > > >    frequent but not too far apart.
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    Ensure new features become mainstream in a reasonable
> > amount
> > > > of
> > > > > > > time.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Specifically,
> > > > > > > > >
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    We will accumulate forward-incompatible changes targeted
> > at
> > > > the
> > > > > > next
> > > > > > > > >    major version of the Parquet spec (for example Version
> 3).
> > > > These
> > > > > > > > > are called “In
> > > > > > > > >    preview”
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    The same bar applies as before (two implementations,
> > > > > > cross-testing,
> > > > > > > …
> > > > > > > > >    <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > > >)
> > > > > > > > >    to add these features in preview in the spec.
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    While in preview they can be used for writing with a
> > feature
> > > > > flag,
> > > > > > > in
> > > > > > > > >    particular to allow integration testing. All
> > implementations
> > > > are
> > > > > > > > > encouraged
> > > > > > > > >    to start being able to read it ASAP (at least two
> > distinct OSS
> > > > > > > > >    implementations are already required to reach this
> stage).
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    These new changes will automatically go into the next
> > major
> > > > > > version.
> > > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    We will have a community vote to close and adopt the
> next
> > > > major
> > > > > > > > version.
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    At this point these features are no longer in preview.
> > Systems
> > > > > > > > >    supporting the new version of Parquet (example: Parquet
> > V3)
> > > > can
> > > > > > > start
> > > > > > > > > using
> > > > > > > > >    it for writing new files by default. (Or communicate
> what
> > they
> > > > > > > support
> > > > > > > > >    reading and what they write into files).
> > > > > > > > >    -
> > > > > > > > >
> > > > > > > > >    In an environment that requires compatibility with at
> > least
> > > > one
> > > > > > > system
> > > > > > > > >    that doesn’t support the latest version of Parquet yet,
> > one
> > > > can
> > > > > > pin
> > > > > > > > to a
> > > > > > > > >    specific version by passing a dedicated option to the
> > writer.
> > > > > > > > (example,
> > > > > > > > >    support reading Parquet V3 but opt to only write Parquet
> > V2
> > > > > until
> > > > > > > the
> > > > > > > > >    environment has upgraded).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > .
> > > > > > > > .
> > > > > > > > > .
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by PRATEEK GAUR <pr...@gmail.com>.
+1 (non-binding).

Thanks to everyone who helped move this proposal.

On Tue, Aug 4, 2026 at 9:42 PM Ed Seidl <et...@apache.org> wrote:

> +1 (non-binding)
>
> Thanks to all who helped move this forward.
>
> On 2026/08/05 03:05:38 Daniel Weeks wrote:
> > +1 (binding)
> >
> > On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > > dev@parquet.apache.org> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Great work with the proposal. Time to start hashing out the details!
> > > >
> > > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > > dev@parquet.apache.org>
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Thank you Julien, Ryan, and everyone else involved for pushing this
> > > > > forward!
> > > > >
> > > > > — Div
> > > > >
> > > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > I agree with Neelesh, I believe this will be a major step
> forward for
> > > > > > communicating compatibility across the ecosystem
> > > > > >
> > > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > > neeleshssalian@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Thank you for all the work that went into getting this to a
> good
> > > > place.
> > > > > > > This is a great next step for the community.
> > > > > > >
> > > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <julien@apache.org
> >
> > > > wrote:
> > > > > > >
> > > > > > > > Hello everyone,
> > > > > > > >
> > > > > > > > Following questions on the the previous vote
> > > > > > > > <
> > > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > > > > thread,
> > > > > > > > here is a new vote essentially proposing the same thing but
> > > > > clarifying
> > > > > > > the
> > > > > > > > specific points raised then. This is the result of our
> > > discussions
> > > > > over
> > > > > > > the
> > > > > > > > last two weeks. With the direction set, we'll work on the
> linked
> > > > > design
> > > > > > > to
> > > > > > > > finalize the implementation details. We decided to start a
> fresh
> > > > vote
> > > > > > to
> > > > > > > > remove ambiguity of clarifying while voting is happening. See
> > > > below.
> > > > > > > >
> > > > > > > > Julien
> > > > > > > >
> > > > > > > > This vote is to formalize our intent to use major version
> numbers
> > > > to
> > > > > > > bundle
> > > > > > > > groups of new features in Parquet. This is especially
> important
> > > to
> > > > > > enable
> > > > > > > > the safe roll-out of forward incompatible features
> (examples: new
> > > > > > > > encodings). We will separately iron out the implementation
> > > details
> > > > in
> > > > > > > > the Parquet
> > > > > > > > Versioning doc
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > > >
> > > > > > > > based on the principles below.
> > > > > > > >
> > > > > > > > Goals:
> > > > > > > >
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    Have a clear definition of what is forward compatible or
> not.
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    Have a clear definition of what supporting a specific
> Parquet
> > > > > > version
> > > > > > > >    means (for write and for read).
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    Have clear version numbers for the ecosystem to
> coordinate on
> > > > > what’s
> > > > > > > >    coming in the next version. Pragmatism will prevail by
> making
> > > > them
> > > > > > not
> > > > > > > > too
> > > > > > > >    frequent but not too far apart.
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    Ensure new features become mainstream in a reasonable
> amount
> > > of
> > > > > > time.
> > > > > > > >
> > > > > > > >
> > > > > > > > Specifically,
> > > > > > > >
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    We will accumulate forward-incompatible changes targeted
> at
> > > the
> > > > > next
> > > > > > > >    major version of the Parquet spec (for example Version 3).
> > > These
> > > > > > > > are called “In
> > > > > > > >    preview”
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    The same bar applies as before (two implementations,
> > > > > cross-testing,
> > > > > > …
> > > > > > > >    <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > > >)
> > > > > > > >    to add these features in preview in the spec.
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    While in preview they can be used for writing with a
> feature
> > > > flag,
> > > > > > in
> > > > > > > >    particular to allow integration testing. All
> implementations
> > > are
> > > > > > > > encouraged
> > > > > > > >    to start being able to read it ASAP (at least two
> distinct OSS
> > > > > > > >    implementations are already required to reach this stage).
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    These new changes will automatically go into the next
> major
> > > > > version.
> > > > > > > >    (pragmatism applies for exceptions)
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    We will have a community vote to close and adopt the next
> > > major
> > > > > > > version.
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    At this point these features are no longer in preview.
> Systems
> > > > > > > >    supporting the new version of Parquet (example: Parquet
> V3)
> > > can
> > > > > > start
> > > > > > > > using
> > > > > > > >    it for writing new files by default. (Or communicate what
> they
> > > > > > support
> > > > > > > >    reading and what they write into files).
> > > > > > > >    -
> > > > > > > >
> > > > > > > >    In an environment that requires compatibility with at
> least
> > > one
> > > > > > system
> > > > > > > >    that doesn’t support the latest version of Parquet yet,
> one
> > > can
> > > > > pin
> > > > > > > to a
> > > > > > > >    specific version by passing a dedicated option to the
> writer.
> > > > > > > (example,
> > > > > > > >    support reading Parquet V3 but opt to only write Parquet
> V2
> > > > until
> > > > > > the
> > > > > > > >    environment has upgraded).
> > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > .
> > > > > > > .
> > > > > > > > .
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Ed Seidl <et...@apache.org>.
+1 (non-binding)

Thanks to all who helped move this forward.

On 2026/08/05 03:05:38 Daniel Weeks wrote:
> +1 (binding)
> 
> On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:
> 
> > +1
> >
> > On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> > dev@parquet.apache.org> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Great work with the proposal. Time to start hashing out the details!
> > >
> > > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > > dev@parquet.apache.org>
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Thank you Julien, Ryan, and everyone else involved for pushing this
> > > > forward!
> > > >
> > > > — Div
> > > >
> > > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com>
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > I agree with Neelesh, I believe this will be a major step forward for
> > > > > communicating compatibility across the ecosystem
> > > > >
> > > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > > neeleshssalian@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Thank you for all the work that went into getting this to a good
> > > place.
> > > > > > This is a great next step for the community.
> > > > > >
> > > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > Hello everyone,
> > > > > > >
> > > > > > > Following questions on the the previous vote
> > > > > > > <
> > https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > > > thread,
> > > > > > > here is a new vote essentially proposing the same thing but
> > > > clarifying
> > > > > > the
> > > > > > > specific points raised then. This is the result of our
> > discussions
> > > > over
> > > > > > the
> > > > > > > last two weeks. With the direction set, we'll work on the linked
> > > > design
> > > > > > to
> > > > > > > finalize the implementation details. We decided to start a fresh
> > > vote
> > > > > to
> > > > > > > remove ambiguity of clarifying while voting is happening. See
> > > below.
> > > > > > >
> > > > > > > Julien
> > > > > > >
> > > > > > > This vote is to formalize our intent to use major version numbers
> > > to
> > > > > > bundle
> > > > > > > groups of new features in Parquet. This is especially important
> > to
> > > > > enable
> > > > > > > the safe roll-out of forward incompatible features (examples: new
> > > > > > > encodings). We will separately iron out the implementation
> > details
> > > in
> > > > > > > the Parquet
> > > > > > > Versioning doc
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > > >
> > > > > > > based on the principles below.
> > > > > > >
> > > > > > > Goals:
> > > > > > >
> > > > > > >    -
> > > > > > >
> > > > > > >    Have a clear definition of what is forward compatible or not.
> > > > > > >    -
> > > > > > >
> > > > > > >    Have a clear definition of what supporting a specific Parquet
> > > > > version
> > > > > > >    means (for write and for read).
> > > > > > >    -
> > > > > > >
> > > > > > >    Have clear version numbers for the ecosystem to coordinate on
> > > > what’s
> > > > > > >    coming in the next version. Pragmatism will prevail by making
> > > them
> > > > > not
> > > > > > > too
> > > > > > >    frequent but not too far apart.
> > > > > > >    -
> > > > > > >
> > > > > > >    Ensure new features become mainstream in a reasonable amount
> > of
> > > > > time.
> > > > > > >
> > > > > > >
> > > > > > > Specifically,
> > > > > > >
> > > > > > >    -
> > > > > > >
> > > > > > >    We will accumulate forward-incompatible changes targeted at
> > the
> > > > next
> > > > > > >    major version of the Parquet spec (for example Version 3).
> > These
> > > > > > > are called “In
> > > > > > >    preview”
> > > > > > >    -
> > > > > > >
> > > > > > >    The same bar applies as before (two implementations,
> > > > cross-testing,
> > > > > …
> > > > > > >    <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > > >)
> > > > > > >    to add these features in preview in the spec.
> > > > > > >    -
> > > > > > >
> > > > > > >    While in preview they can be used for writing with a feature
> > > flag,
> > > > > in
> > > > > > >    particular to allow integration testing. All implementations
> > are
> > > > > > > encouraged
> > > > > > >    to start being able to read it ASAP (at least two distinct OSS
> > > > > > >    implementations are already required to reach this stage).
> > > > > > >    -
> > > > > > >
> > > > > > >    These new changes will automatically go into the next major
> > > > version.
> > > > > > >    (pragmatism applies for exceptions)
> > > > > > >    -
> > > > > > >
> > > > > > >    We will have a community vote to close and adopt the next
> > major
> > > > > > version.
> > > > > > >    -
> > > > > > >
> > > > > > >    At this point these features are no longer in preview. Systems
> > > > > > >    supporting the new version of Parquet (example: Parquet V3)
> > can
> > > > > start
> > > > > > > using
> > > > > > >    it for writing new files by default. (Or communicate what they
> > > > > support
> > > > > > >    reading and what they write into files).
> > > > > > >    -
> > > > > > >
> > > > > > >    In an environment that requires compatibility with at least
> > one
> > > > > system
> > > > > > >    that doesn’t support the latest version of Parquet yet, one
> > can
> > > > pin
> > > > > > to a
> > > > > > >    specific version by passing a dedicated option to the writer.
> > > > > > (example,
> > > > > > >    support reading Parquet V3 but opt to only write Parquet V2
> > > until
> > > > > the
> > > > > > >    environment has upgraded).
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > .
> > > > > > .
> > > > > > > .
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Daniel Weeks <dw...@apache.org>.
+1 (binding)

On Tue, Aug 4, 2026, 8:04 PM Gang Wu <us...@gmail.com> wrote:

> +1
>
> On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
> dev@parquet.apache.org> wrote:
>
> > +1 (non-binding)
> >
> > Great work with the proposal. Time to start hashing out the details!
> >
> > On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> > dev@parquet.apache.org>
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Thank you Julien, Ryan, and everyone else involved for pushing this
> > > forward!
> > >
> > > — Div
> > >
> > > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com>
> wrote:
> > >
> > > > +1
> > > >
> > > > I agree with Neelesh, I believe this will be a major step forward for
> > > > communicating compatibility across the ecosystem
> > > >
> > > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> > neeleshssalian@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Thank you for all the work that went into getting this to a good
> > place.
> > > > > This is a great next step for the community.
> > > > >
> > > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org>
> > wrote:
> > > > >
> > > > > > Hello everyone,
> > > > > >
> > > > > > Following questions on the the previous vote
> > > > > > <
> https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > > thread,
> > > > > > here is a new vote essentially proposing the same thing but
> > > clarifying
> > > > > the
> > > > > > specific points raised then. This is the result of our
> discussions
> > > over
> > > > > the
> > > > > > last two weeks. With the direction set, we'll work on the linked
> > > design
> > > > > to
> > > > > > finalize the implementation details. We decided to start a fresh
> > vote
> > > > to
> > > > > > remove ambiguity of clarifying while voting is happening. See
> > below.
> > > > > >
> > > > > > Julien
> > > > > >
> > > > > > This vote is to formalize our intent to use major version numbers
> > to
> > > > > bundle
> > > > > > groups of new features in Parquet. This is especially important
> to
> > > > enable
> > > > > > the safe roll-out of forward incompatible features (examples: new
> > > > > > encodings). We will separately iron out the implementation
> details
> > in
> > > > > > the Parquet
> > > > > > Versioning doc
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > > >
> > > > > > based on the principles below.
> > > > > >
> > > > > > Goals:
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    Have a clear definition of what is forward compatible or not.
> > > > > >    -
> > > > > >
> > > > > >    Have a clear definition of what supporting a specific Parquet
> > > > version
> > > > > >    means (for write and for read).
> > > > > >    -
> > > > > >
> > > > > >    Have clear version numbers for the ecosystem to coordinate on
> > > what’s
> > > > > >    coming in the next version. Pragmatism will prevail by making
> > them
> > > > not
> > > > > > too
> > > > > >    frequent but not too far apart.
> > > > > >    -
> > > > > >
> > > > > >    Ensure new features become mainstream in a reasonable amount
> of
> > > > time.
> > > > > >
> > > > > >
> > > > > > Specifically,
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    We will accumulate forward-incompatible changes targeted at
> the
> > > next
> > > > > >    major version of the Parquet spec (for example Version 3).
> These
> > > > > > are called “In
> > > > > >    preview”
> > > > > >    -
> > > > > >
> > > > > >    The same bar applies as before (two implementations,
> > > cross-testing,
> > > > …
> > > > > >    <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > > >)
> > > > > >    to add these features in preview in the spec.
> > > > > >    -
> > > > > >
> > > > > >    While in preview they can be used for writing with a feature
> > flag,
> > > > in
> > > > > >    particular to allow integration testing. All implementations
> are
> > > > > > encouraged
> > > > > >    to start being able to read it ASAP (at least two distinct OSS
> > > > > >    implementations are already required to reach this stage).
> > > > > >    -
> > > > > >
> > > > > >    These new changes will automatically go into the next major
> > > version.
> > > > > >    (pragmatism applies for exceptions)
> > > > > >    -
> > > > > >
> > > > > >    We will have a community vote to close and adopt the next
> major
> > > > > version.
> > > > > >    -
> > > > > >
> > > > > >    At this point these features are no longer in preview. Systems
> > > > > >    supporting the new version of Parquet (example: Parquet V3)
> can
> > > > start
> > > > > > using
> > > > > >    it for writing new files by default. (Or communicate what they
> > > > support
> > > > > >    reading and what they write into files).
> > > > > >    -
> > > > > >
> > > > > >    In an environment that requires compatibility with at least
> one
> > > > system
> > > > > >    that doesn’t support the latest version of Parquet yet, one
> can
> > > pin
> > > > > to a
> > > > > >    specific version by passing a dedicated option to the writer.
> > > > > (example,
> > > > > >    support reading Parquet V3 but opt to only write Parquet V2
> > until
> > > > the
> > > > > >    environment has upgraded).
> > > > > >
> > > > > >
> > > > > > 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
> > > > .
> > > > > .
> > > > > > .
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Gang Wu <us...@gmail.com>.
+1

On Sun, Aug 2, 2026 at 5:44 AM Alkis Evlogimenos via dev <
dev@parquet.apache.org> wrote:

> +1 (non-binding)
>
> Great work with the proposal. Time to start hashing out the details!
>
> On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <
> dev@parquet.apache.org>
> wrote:
>
> > +1 (non-binding)
> >
> > Thank you Julien, Ryan, and everyone else involved for pushing this
> > forward!
> >
> > — Div
> >
> > On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com> wrote:
> >
> > > +1
> > >
> > > I agree with Neelesh, I believe this will be a major step forward for
> > > communicating compatibility across the ecosystem
> > >
> > > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <
> neeleshssalian@gmail.com
> > >
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Thank you for all the work that went into getting this to a good
> place.
> > > > This is a great next step for the community.
> > > >
> > > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org>
> wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > Following questions on the the previous vote
> > > > > <https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > > thread,
> > > > > here is a new vote essentially proposing the same thing but
> > clarifying
> > > > the
> > > > > specific points raised then. This is the result of our discussions
> > over
> > > > the
> > > > > last two weeks. With the direction set, we'll work on the linked
> > design
> > > > to
> > > > > finalize the implementation details. We decided to start a fresh
> vote
> > > to
> > > > > remove ambiguity of clarifying while voting is happening. See
> below.
> > > > >
> > > > > Julien
> > > > >
> > > > > This vote is to formalize our intent to use major version numbers
> to
> > > > bundle
> > > > > groups of new features in Parquet. This is especially important to
> > > enable
> > > > > the safe roll-out of forward incompatible features (examples: new
> > > > > encodings). We will separately iron out the implementation details
> in
> > > > > the Parquet
> > > > > Versioning doc
> > > > > <
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > > >
> > > > > based on the principles below.
> > > > >
> > > > > Goals:
> > > > >
> > > > >    -
> > > > >
> > > > >    Have a clear definition of what is forward compatible or not.
> > > > >    -
> > > > >
> > > > >    Have a clear definition of what supporting a specific Parquet
> > > version
> > > > >    means (for write and for read).
> > > > >    -
> > > > >
> > > > >    Have clear version numbers for the ecosystem to coordinate on
> > what’s
> > > > >    coming in the next version. Pragmatism will prevail by making
> them
> > > not
> > > > > too
> > > > >    frequent but not too far apart.
> > > > >    -
> > > > >
> > > > >    Ensure new features become mainstream in a reasonable amount of
> > > time.
> > > > >
> > > > >
> > > > > Specifically,
> > > > >
> > > > >    -
> > > > >
> > > > >    We will accumulate forward-incompatible changes targeted at the
> > next
> > > > >    major version of the Parquet spec (for example Version 3). These
> > > > > are called “In
> > > > >    preview”
> > > > >    -
> > > > >
> > > > >    The same bar applies as before (two implementations,
> > cross-testing,
> > > …
> > > > >    <
> > > > >
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > > >)
> > > > >    to add these features in preview in the spec.
> > > > >    -
> > > > >
> > > > >    While in preview they can be used for writing with a feature
> flag,
> > > in
> > > > >    particular to allow integration testing. All implementations are
> > > > > encouraged
> > > > >    to start being able to read it ASAP (at least two distinct OSS
> > > > >    implementations are already required to reach this stage).
> > > > >    -
> > > > >
> > > > >    These new changes will automatically go into the next major
> > version.
> > > > >    (pragmatism applies for exceptions)
> > > > >    -
> > > > >
> > > > >    We will have a community vote to close and adopt the next major
> > > > version.
> > > > >    -
> > > > >
> > > > >    At this point these features are no longer in preview. Systems
> > > > >    supporting the new version of Parquet (example: Parquet V3) can
> > > start
> > > > > using
> > > > >    it for writing new files by default. (Or communicate what they
> > > support
> > > > >    reading and what they write into files).
> > > > >    -
> > > > >
> > > > >    In an environment that requires compatibility with at least one
> > > system
> > > > >    that doesn’t support the latest version of Parquet yet, one can
> > pin
> > > > to a
> > > > >    specific version by passing a dedicated option to the writer.
> > > > (example,
> > > > >    support reading Parquet V3 but opt to only write Parquet V2
> until
> > > the
> > > > >    environment has upgraded).
> > > > >
> > > > >
> > > > > 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
> > > .
> > > > .
> > > > > .
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Alkis Evlogimenos via dev <de...@parquet.apache.org>.
+1 (non-binding)

Great work with the proposal. Time to start hashing out the details!

On Sat, Aug 1, 2026 at 11:53 AM Divjot Arora via dev <de...@parquet.apache.org>
wrote:

> +1 (non-binding)
>
> Thank you Julien, Ryan, and everyone else involved for pushing this
> forward!
>
> — Div
>
> On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com> wrote:
>
> > +1
> >
> > I agree with Neelesh, I believe this will be a major step forward for
> > communicating compatibility across the ecosystem
> >
> > On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <neeleshssalian@gmail.com
> >
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Thank you for all the work that went into getting this to a good place.
> > > This is a great next step for the community.
> > >
> > > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org> wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > Following questions on the the previous vote
> > > > <https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > > thread,
> > > > here is a new vote essentially proposing the same thing but
> clarifying
> > > the
> > > > specific points raised then. This is the result of our discussions
> over
> > > the
> > > > last two weeks. With the direction set, we'll work on the linked
> design
> > > to
> > > > finalize the implementation details. We decided to start a fresh vote
> > to
> > > > remove ambiguity of clarifying while voting is happening. See below.
> > > >
> > > > Julien
> > > >
> > > > This vote is to formalize our intent to use major version numbers to
> > > bundle
> > > > groups of new features in Parquet. This is especially important to
> > enable
> > > > the safe roll-out of forward incompatible features (examples: new
> > > > encodings). We will separately iron out the implementation details in
> > > > the Parquet
> > > > Versioning doc
> > > > <
> > > >
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > > >
> > > > based on the principles below.
> > > >
> > > > Goals:
> > > >
> > > >    -
> > > >
> > > >    Have a clear definition of what is forward compatible or not.
> > > >    -
> > > >
> > > >    Have a clear definition of what supporting a specific Parquet
> > version
> > > >    means (for write and for read).
> > > >    -
> > > >
> > > >    Have clear version numbers for the ecosystem to coordinate on
> what’s
> > > >    coming in the next version. Pragmatism will prevail by making them
> > not
> > > > too
> > > >    frequent but not too far apart.
> > > >    -
> > > >
> > > >    Ensure new features become mainstream in a reasonable amount of
> > time.
> > > >
> > > >
> > > > Specifically,
> > > >
> > > >    -
> > > >
> > > >    We will accumulate forward-incompatible changes targeted at the
> next
> > > >    major version of the Parquet spec (for example Version 3). These
> > > > are called “In
> > > >    preview”
> > > >    -
> > > >
> > > >    The same bar applies as before (two implementations,
> cross-testing,
> > …
> > > >    <
> > > >
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > > >)
> > > >    to add these features in preview in the spec.
> > > >    -
> > > >
> > > >    While in preview they can be used for writing with a feature flag,
> > in
> > > >    particular to allow integration testing. All implementations are
> > > > encouraged
> > > >    to start being able to read it ASAP (at least two distinct OSS
> > > >    implementations are already required to reach this stage).
> > > >    -
> > > >
> > > >    These new changes will automatically go into the next major
> version.
> > > >    (pragmatism applies for exceptions)
> > > >    -
> > > >
> > > >    We will have a community vote to close and adopt the next major
> > > version.
> > > >    -
> > > >
> > > >    At this point these features are no longer in preview. Systems
> > > >    supporting the new version of Parquet (example: Parquet V3) can
> > start
> > > > using
> > > >    it for writing new files by default. (Or communicate what they
> > support
> > > >    reading and what they write into files).
> > > >    -
> > > >
> > > >    In an environment that requires compatibility with at least one
> > system
> > > >    that doesn’t support the latest version of Parquet yet, one can
> pin
> > > to a
> > > >    specific version by passing a dedicated option to the writer.
> > > (example,
> > > >    support reading Parquet V3 but opt to only write Parquet V2 until
> > the
> > > >    environment has upgraded).
> > > >
> > > >
> > > > 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
> > .
> > > .
> > > > .
> > > >
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Divjot Arora via dev <de...@parquet.apache.org>.
+1 (non-binding)

Thank you Julien, Ryan, and everyone else involved for pushing this forward!

— Div

On Sat, Aug 1, 2026 at 08:42 Andrew Lamb <an...@gmail.com> wrote:

> +1
>
> I agree with Neelesh, I believe this will be a major step forward for
> communicating compatibility across the ecosystem
>
> On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <ne...@gmail.com>
> wrote:
>
> > +1 (non-binding)
> >
> > Thank you for all the work that went into getting this to a good place.
> > This is a great next step for the community.
> >
> > On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org> wrote:
> >
> > > Hello everyone,
> > >
> > > Following questions on the the previous vote
> > > <https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> > thread,
> > > here is a new vote essentially proposing the same thing but clarifying
> > the
> > > specific points raised then. This is the result of our discussions over
> > the
> > > last two weeks. With the direction set, we'll work on the linked design
> > to
> > > finalize the implementation details. We decided to start a fresh vote
> to
> > > remove ambiguity of clarifying while voting is happening. See below.
> > >
> > > Julien
> > >
> > > This vote is to formalize our intent to use major version numbers to
> > bundle
> > > groups of new features in Parquet. This is especially important to
> enable
> > > the safe roll-out of forward incompatible features (examples: new
> > > encodings). We will separately iron out the implementation details in
> > > the Parquet
> > > Versioning doc
> > > <
> > >
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > > >
> > > based on the principles below.
> > >
> > > Goals:
> > >
> > >    -
> > >
> > >    Have a clear definition of what is forward compatible or not.
> > >    -
> > >
> > >    Have a clear definition of what supporting a specific Parquet
> version
> > >    means (for write and for read).
> > >    -
> > >
> > >    Have clear version numbers for the ecosystem to coordinate on what’s
> > >    coming in the next version. Pragmatism will prevail by making them
> not
> > > too
> > >    frequent but not too far apart.
> > >    -
> > >
> > >    Ensure new features become mainstream in a reasonable amount of
> time.
> > >
> > >
> > > Specifically,
> > >
> > >    -
> > >
> > >    We will accumulate forward-incompatible changes targeted at the next
> > >    major version of the Parquet spec (for example Version 3). These
> > > are called “In
> > >    preview”
> > >    -
> > >
> > >    The same bar applies as before (two implementations, cross-testing,
> …
> > >    <
> > >
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > > >)
> > >    to add these features in preview in the spec.
> > >    -
> > >
> > >    While in preview they can be used for writing with a feature flag,
> in
> > >    particular to allow integration testing. All implementations are
> > > encouraged
> > >    to start being able to read it ASAP (at least two distinct OSS
> > >    implementations are already required to reach this stage).
> > >    -
> > >
> > >    These new changes will automatically go into the next major version.
> > >    (pragmatism applies for exceptions)
> > >    -
> > >
> > >    We will have a community vote to close and adopt the next major
> > version.
> > >    -
> > >
> > >    At this point these features are no longer in preview. Systems
> > >    supporting the new version of Parquet (example: Parquet V3) can
> start
> > > using
> > >    it for writing new files by default. (Or communicate what they
> support
> > >    reading and what they write into files).
> > >    -
> > >
> > >    In an environment that requires compatibility with at least one
> system
> > >    that doesn’t support the latest version of Parquet yet, one can pin
> > to a
> > >    specific version by passing a dedicated option to the writer.
> > (example,
> > >    support reading Parquet V3 but opt to only write Parquet V2 until
> the
> > >    environment has upgraded).
> > >
> > >
> > > 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
> .
> > .
> > > .
> > >
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Andrew Lamb <an...@gmail.com>.
+1

I agree with Neelesh, I believe this will be a major step forward for
communicating compatibility across the ecosystem

On Fri, Jul 31, 2026 at 5:13 PM Neelesh Salian <ne...@gmail.com>
wrote:

> +1 (non-binding)
>
> Thank you for all the work that went into getting this to a good place.
> This is a great next step for the community.
>
> On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org> wrote:
>
> > Hello everyone,
> >
> > Following questions on the the previous vote
> > <https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq>
> thread,
> > here is a new vote essentially proposing the same thing but clarifying
> the
> > specific points raised then. This is the result of our discussions over
> the
> > last two weeks. With the direction set, we'll work on the linked design
> to
> > finalize the implementation details. We decided to start a fresh vote to
> > remove ambiguity of clarifying while voting is happening. See below.
> >
> > Julien
> >
> > This vote is to formalize our intent to use major version numbers to
> bundle
> > groups of new features in Parquet. This is especially important to enable
> > the safe roll-out of forward incompatible features (examples: new
> > encodings). We will separately iron out the implementation details in
> > the Parquet
> > Versioning doc
> > <
> >
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> > >
> > based on the principles below.
> >
> > Goals:
> >
> >    -
> >
> >    Have a clear definition of what is forward compatible or not.
> >    -
> >
> >    Have a clear definition of what supporting a specific Parquet version
> >    means (for write and for read).
> >    -
> >
> >    Have clear version numbers for the ecosystem to coordinate on what’s
> >    coming in the next version. Pragmatism will prevail by making them not
> > too
> >    frequent but not too far apart.
> >    -
> >
> >    Ensure new features become mainstream in a reasonable amount of time.
> >
> >
> > Specifically,
> >
> >    -
> >
> >    We will accumulate forward-incompatible changes targeted at the next
> >    major version of the Parquet spec (for example Version 3). These
> > are called “In
> >    preview”
> >    -
> >
> >    The same bar applies as before (two implementations, cross-testing, …
> >    <
> >
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> > >)
> >    to add these features in preview in the spec.
> >    -
> >
> >    While in preview they can be used for writing with a feature flag, in
> >    particular to allow integration testing. All implementations are
> > encouraged
> >    to start being able to read it ASAP (at least two distinct OSS
> >    implementations are already required to reach this stage).
> >    -
> >
> >    These new changes will automatically go into the next major version.
> >    (pragmatism applies for exceptions)
> >    -
> >
> >    We will have a community vote to close and adopt the next major
> version.
> >    -
> >
> >    At this point these features are no longer in preview. Systems
> >    supporting the new version of Parquet (example: Parquet V3) can start
> > using
> >    it for writing new files by default. (Or communicate what they support
> >    reading and what they write into files).
> >    -
> >
> >    In an environment that requires compatibility with at least one system
> >    that doesn’t support the latest version of Parquet yet, one can pin
> to a
> >    specific version by passing a dedicated option to the writer.
> (example,
> >    support reading Parquet V3 but opt to only write Parquet V2 until the
> >    environment has upgraded).
> >
> >
> > 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 .
> .
> > .
> >
>

Re: [VOTE] Use versions to release forward-incompatible changes (take 2)

Posted by Neelesh Salian <ne...@gmail.com>.
+1 (non-binding)

Thank you for all the work that went into getting this to a good place.
This is a great next step for the community.

On Fri, Jul 31, 2026 at 14:07 Julien Le Dem <ju...@apache.org> wrote:

> Hello everyone,
>
> Following questions on the the previous vote
> <https://lists.apache.org/thread/o8bwmqdy1wf0z459h65x43lnsrldrvhq> thread,
> here is a new vote essentially proposing the same thing but clarifying the
> specific points raised then. This is the result of our discussions over the
> last two weeks. With the direction set, we'll work on the linked design to
> finalize the implementation details. We decided to start a fresh vote to
> remove ambiguity of clarifying while voting is happening. See below.
>
> Julien
>
> This vote is to formalize our intent to use major version numbers to bundle
> groups of new features in Parquet. This is especially important to enable
> the safe roll-out of forward incompatible features (examples: new
> encodings). We will separately iron out the implementation details in
> the Parquet
> Versioning doc
> <
> https://docs.google.com/document/d/19bOTy1WcLs9NP88DrysG4wG50pM6gmIFaSEWzkxUeJw/edit?tab=t.0#heading=h.qlhnuhge8ke2
> >
> based on the principles below.
>
> Goals:
>
>    -
>
>    Have a clear definition of what is forward compatible or not.
>    -
>
>    Have a clear definition of what supporting a specific Parquet version
>    means (for write and for read).
>    -
>
>    Have clear version numbers for the ecosystem to coordinate on what’s
>    coming in the next version. Pragmatism will prevail by making them not
> too
>    frequent but not too far apart.
>    -
>
>    Ensure new features become mainstream in a reasonable amount of time.
>
>
> Specifically,
>
>    -
>
>    We will accumulate forward-incompatible changes targeted at the next
>    major version of the Parquet spec (for example Version 3). These
> are called “In
>    preview”
>    -
>
>    The same bar applies as before (two implementations, cross-testing, …
>    <
> https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#additionschanges-to-the-format
> >)
>    to add these features in preview in the spec.
>    -
>
>    While in preview they can be used for writing with a feature flag, in
>    particular to allow integration testing. All implementations are
> encouraged
>    to start being able to read it ASAP (at least two distinct OSS
>    implementations are already required to reach this stage).
>    -
>
>    These new changes will automatically go into the next major version.
>    (pragmatism applies for exceptions)
>    -
>
>    We will have a community vote to close and adopt the next major version.
>    -
>
>    At this point these features are no longer in preview. Systems
>    supporting the new version of Parquet (example: Parquet V3) can start
> using
>    it for writing new files by default. (Or communicate what they support
>    reading and what they write into files).
>    -
>
>    In an environment that requires compatibility with at least one system
>    that doesn’t support the latest version of Parquet yet, one can pin to a
>    specific version by passing a dedicated option to the writer. (example,
>    support reading Parquet V3 but opt to only write Parquet V2 until the
>    environment has upgraded).
>
>
> 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 . .
> .
>