+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 <CAJPUwMC0M3tRrDhjwrea=a8ym_vyfzc5flufznkwjq7w_s2...@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 <wesmck...@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#
