You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Wes McKinney <we...@gmail.com> on 2019/07/26 19:33:30 UTC
[VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
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#
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Wes McKinney <we...@gmail.com>.
On Mon, Jul 29, 2019 at 8:07 AM Antoine Pitrou <an...@python.org> wrote:
>
>
> Le 26/07/2019 à 21:33, Wes McKinney a écrit :
> > 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.
>
> Will a new supported FORMAT version always bump the LIBRARY to the next
> MAJOR version?
>
Yes
> > 5. BACKWARD COMPATIBILITY GUARANTEE: A newer versioned client library
> > will be able to read any data and metadata produced by an older client
> > library.
>
> Should this be "starting from 1.0.0"? Did we have some format-breaking
> changes before?
>
Implicitly this entire list of statements is starting with 1.0.0
And yes we did, see
https://github.com/apache/arrow/blob/master/format/Schema.fbs#L22
> Regards
>
> Antoine.
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Antoine Pitrou <an...@python.org>.
Le 26/07/2019 à 21:33, Wes McKinney a écrit :
> 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.
Will a new supported FORMAT version always bump the LIBRARY to the next
MAJOR 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.
Should this be "starting from 1.0.0"? Did we have some format-breaking
changes before?
Regards
Antoine.
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Micah Kornfield <em...@gmail.com>.
+1 (non-binding) Adopt these version conventions and compatibility
guarantees as of Apache Arrow 1.0.0
On Fri, Jul 26, 2019 at 12:34 PM 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#
>
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Wes McKinney <we...@gmail.com>.
On Mon, Jul 29, 2019 at 4:28 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
> +1
>
> But I want to confirm the following:
>
> > 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.
>
> We'll release 2.0.0 as the next release of 1.0.0. Right?
>
Yes
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "[VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for Arrow 1.0.0 and beyond" 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#
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes
for Arrow 1.0.0 and beyond
Posted by Sutou Kouhei <ko...@clear-code.com>.
+1
But I want to confirm the following:
> 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.
We'll release 2.0.0 as the next release of 1.0.0. Right?
Thanks,
--
kou
In <CA...@mail.gmail.com>
"[VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for Arrow 1.0.0 and beyond" 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
Posted by 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#
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by 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#
> > > >
> > >
> > >
> > >
> > >
> >
>
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Bryan Cutler <cu...@gmail.com>.
+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#
> > >
> >
> >
> >
> >
>
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for Arrow 1.0.0 and beyond
Posted by "Uwe L. Korn" <uw...@xhochy.com>.
+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#
> >
>
>
>
>
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes
for Arrow 1.0.0 and beyond
Posted by Antoine Pitrou <so...@pitrou.net>.
+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#
>
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Wes McKinney <we...@gmail.com>.
On Mon, Jul 29, 2019 at 8:23 AM Francois Saint-Jacques
<fs...@gmail.com> wrote:
>
> Do we bump the library version on changes from _any_ language
> implementation, or just the C++/Java version?
Yes (any language)
> François
>
> On Fri, Jul 26, 2019 at 3:34 PM 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#
Re: [VOTE] Adopt FORMAT and LIBRARY SemVer-based version schemes for
Arrow 1.0.0 and beyond
Posted by Francois Saint-Jacques <fs...@gmail.com>.
Do we bump the library version on changes from _any_ language
implementation, or just the C++/Java version?
François
On Fri, Jul 26, 2019 at 3:34 PM 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#