+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 <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# > > > > > > > > > > > >
