On Mon, Jul 29, 2019 at 8:23 AM Francois Saint-Jacques <fsaintjacq...@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 <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#
