Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for Arrow 1.0.0 and beyond

[Jacques Nadeau <ja...@apache.org>]

Looks good. +1 from me. Thanks for driving this to conclusion.

On Wed, Jul 31, 2019, 12:04 PM Bryan Cutler <cu...@gmail.com> wrote:

> +1 (non-binding)
>
> On Wed, Jul 31, 2019 at 8:59 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>
> > +1 from me.
> >
> > I really like the separate versions
> >
> > Uwe
> >
> > On Tue, Jul 30, 2019, at 2:21 PM, Antoine Pitrou wrote:
> > >
> > > +1 from me.
> > >
> > > Regards
> > >
> > > Antoine.
> > >
> > >
> > >
> > > On Fri, 26 Jul 2019 14:33:30 -0500
> > > Wes McKinney <we...@gmail.com> wrote:
> > > > hello,
> > > >
> > > > As discussed on the mailing list thread [1], Micah Kornfield has
> > > > proposed a version scheme for the project to take effect starting
> with
> > > > the 1.0.0 release. See document [2] containing a discussion of the
> > > > issues involved.
> > > >
> > > > To summarize my understanding of the plan:
> > > >
> > > > 1. TWO VERSIONS: As of 1.0.0, we establish separate FORMAT and
> LIBRARY
> > > > versions. Currently there is only a single version number.
> > > >
> > > > 2. SEMANTIC VERSIONING: We follow https://semver.org/ with regards
> to
> > > > communicating library API changes. Given the project's pace of
> > > > evolution, most releases are likely to be MAJOR releases according to
> > > > SemVer principles.
> > > >
> > > > 3. RELEASES: Releases of the project will be named according to the
> > > > LIBRARY version. A major release may or may not change the FORMAT
> > > > version. When a LIBRARY version has been released for a new FORMAT
> > > > version, the latter is considered to be released and official.
> > > >
> > > > 4. Each LIBRARY version will have a corresponding FORMAT version. For
> > > > example, LIBRARY versions 2.0.0 and 3.0.0 may track FORMAT version
> > > > 1.0.0. The idea is that FORMAT version will change less often than
> > > > LIBRARY version.
> > > >
> > > > 5. BACKWARD COMPATIBILITY GUARANTEE: A newer versioned client library
> > > > will be able to read any data and metadata produced by an older
> client
> > > > library.
> > > >
> > > > 6. FORWARD COMPATIBILITY GUARANTEE: An older client library must be
> > > > able to either read data generated from a new client library or
> detect
> > > > that it cannot properly read the data.
> > > >
> > > > 7. FORMAT MINOR VERSIONS: An increase in the minor version of the
> > > > FORMAT version, such as 1.0.0 to 1.1.0, indicates that 1.1.0 contains
> > > > new features not available in 1.0.0. So long as these features are
> not
> > > > used (such as a new logical data type), forward compatibility is
> > > > preserved.
> > > >
> > > > 8. FORMAT MAJOR VERSIONS: A change in the FORMAT major version
> > > > indicates a disruption to these compatibility guarantees in some way.
> > > > Hopefully we don't have to do this many times in our respective
> > > > lifetimes
> > > >
> > > > If I've misrepresented some aspect of the proposal it's fine to
> > > > discuss more and we can start a new votes.
> > > >
> > > > Please vote to approve this proposal. I'd like to keep this vote open
> > > > for 7 days (until Friday August 2) to allow for ample opportunities
> > > > for the community to have a look.
> > > >
> > > > [ ] +1 Adopt these version conventions and compatibility guarantees
> as
> > > > of Apache Arrow 1.0.0
> > > > [ ] +0
> > > > [ ] -1 I disagree because...
> > > >
> > > > Here is my vote: +1
> > > >
> > > > Thanks
> > > > Wes
> > > >
> > > > [1]:
> >
> https://lists.apache.org/thread.html/5715a4d402c835d22d929a8069c5c0cf232077a660ee98639d544af8@%3Cdev.arrow.apache.org%3E
> > > > [2]:
> >
> https://docs.google.com/document/d/1uBitWu57rDu85tNHn0NwstAbrlYqor9dPFg_7QaE-nc/edit#
> > > >
> > >
> > >
> > >
> > >
> >
>

[RESULT] [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for Arrow 1.0.0 and beyond

[Wes McKinney <we...@gmail.com>]

The motion carries with 5 binding +1 and 2 non-binding +1 and no other votes

We need to make sure this is properly documented in time for the 1.0.0 release

https://issues.apache.org/jira/browse/ARROW-6164

On Sun, Aug 4, 2019 at 5:04 PM Jacques Nadeau <ja...@apache.org> wrote:
>
> Looks good. +1 from me. Thanks for driving this to conclusion.
>
> On Wed, Jul 31, 2019, 12:04 PM Bryan Cutler <cu...@gmail.com> wrote:
>
> > +1 (non-binding)
> >
> > On Wed, Jul 31, 2019 at 8:59 AM Uwe L. Korn <uw...@xhochy.com> wrote:
> >
> > > +1 from me.
> > >
> > > I really like the separate versions
> > >
> > > Uwe
> > >
> > > On Tue, Jul 30, 2019, at 2:21 PM, Antoine Pitrou wrote:
> > > >
> > > > +1 from me.
> > > >
> > > > Regards
> > > >
> > > > Antoine.
> > > >
> > > >
> > > >
> > > > On Fri, 26 Jul 2019 14:33:30 -0500
> > > > Wes McKinney <we...@gmail.com> wrote:
> > > > > hello,
> > > > >
> > > > > As discussed on the mailing list thread [1], Micah Kornfield has
> > > > > proposed a version scheme for the project to take effect starting
> > with
> > > > > the 1.0.0 release. See document [2] containing a discussion of the
> > > > > issues involved.
> > > > >
> > > > > To summarize my understanding of the plan:
> > > > >
> > > > > 1. TWO VERSIONS: As of 1.0.0, we establish separate FORMAT and
> > LIBRARY
> > > > > versions. Currently there is only a single version number.
> > > > >
> > > > > 2. SEMANTIC VERSIONING: We follow https://semver.org/ with regards
> > to
> > > > > communicating library API changes. Given the project's pace of
> > > > > evolution, most releases are likely to be MAJOR releases according to
> > > > > SemVer principles.
> > > > >
> > > > > 3. RELEASES: Releases of the project will be named according to the
> > > > > LIBRARY version. A major release may or may not change the FORMAT
> > > > > version. When a LIBRARY version has been released for a new FORMAT
> > > > > version, the latter is considered to be released and official.
> > > > >
> > > > > 4. Each LIBRARY version will have a corresponding FORMAT version. For
> > > > > example, LIBRARY versions 2.0.0 and 3.0.0 may track FORMAT version
> > > > > 1.0.0. The idea is that FORMAT version will change less often than
> > > > > LIBRARY version.
> > > > >
> > > > > 5. BACKWARD COMPATIBILITY GUARANTEE: A newer versioned client library
> > > > > will be able to read any data and metadata produced by an older
> > client
> > > > > library.
> > > > >
> > > > > 6. FORWARD COMPATIBILITY GUARANTEE: An older client library must be
> > > > > able to either read data generated from a new client library or
> > detect
> > > > > that it cannot properly read the data.
> > > > >
> > > > > 7. FORMAT MINOR VERSIONS: An increase in the minor version of the
> > > > > FORMAT version, such as 1.0.0 to 1.1.0, indicates that 1.1.0 contains
> > > > > new features not available in 1.0.0. So long as these features are
> > not
> > > > > used (such as a new logical data type), forward compatibility is
> > > > > preserved.
> > > > >
> > > > > 8. FORMAT MAJOR VERSIONS: A change in the FORMAT major version
> > > > > indicates a disruption to these compatibility guarantees in some way.
> > > > > Hopefully we don't have to do this many times in our respective
> > > > > lifetimes
> > > > >
> > > > > If I've misrepresented some aspect of the proposal it's fine to
> > > > > discuss more and we can start a new votes.
> > > > >
> > > > > Please vote to approve this proposal. I'd like to keep this vote open
> > > > > for 7 days (until Friday August 2) to allow for ample opportunities
> > > > > for the community to have a look.
> > > > >
> > > > > [ ] +1 Adopt these version conventions and compatibility guarantees
> > as
> > > > > of Apache Arrow 1.0.0
> > > > > [ ] +0
> > > > > [ ] -1 I disagree because...
> > > > >
> > > > > Here is my vote: +1
> > > > >
> > > > > Thanks
> > > > > Wes
> > > > >
> > > > > [1]:
> > >
> > https://lists.apache.org/thread.html/5715a4d402c835d22d929a8069c5c0cf232077a660ee98639d544af8@%3Cdev.arrow.apache.org%3E
> > > > > [2]:
> > >
> > https://docs.google.com/document/d/1uBitWu57rDu85tNHn0NwstAbrlYqor9dPFg_7QaE-nc/edit#
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >