Hi, I think that 0.14.0 is better for the next version.
People who don't try Apache Arrow yet to wait 1.0.0 will use Apache Arrow when we release 1.0.0. If 1.0.0 satisfies them, we will get more users and contributors by 1.0.0. They may not care protocol stability. They may just care "1.0.0". We'll be able to release less problem 1.0.0 by releasing 0.14.0 as RC for 1.0.0. 0.14.0 will be used more people than 1.0.0-RCX. 0.14.0 users will find critical problems. Thanks, -- kou In <CAK7Z5T885FnCrgZnTfJrm400kq_pz-=azyvgwtheefnxt1e...@mail.gmail.com> "Re: [DISCUSS] Timing of release and making a 1.0.0 release marking Arrow protocol stability" on Fri, 7 Jun 2019 22:28:22 -0700, Micah Kornfield <emkornfi...@gmail.com> wrote: > A few thoughts: > - I think we should iron out the remaining incompatibilities between java > and C++ before going to 1.0.0 (at least Union and NullType), and I'm not > sure I will have time to them before the next release, so I would prefer to > try to aim for the subsequent release to make it 1.0.0 > - For 1.0.0 should we change the metadata format version to a new naming > scheme [1] (seems like more of a hassle then it is worth)? > - I'm a little concerned about the implications for forward-compatibility > restrictions for format changes. For instance the large list types would > not be forward compatible (at least by some definitions), similarly if we > deal with compression [2] it would also seem to not be forward compatible. > Would this mean we bump the format version number for each change even > though they would be backwards compatible? > > Thanks, > Micah > > [1] https://github.com/apache/arrow/blob/master/format/Schema.fbs#L22 > [2] https://issues.apache.org/jira/browse/ARROW-300 > > On Fri, Jun 7, 2019 at 12:42 PM Wes McKinney <wesmck...@gmail.com> wrote: > >> I agree re: marketing value of a 1.0.0 release. >> >> For the record, I think we should continue to allow the API of each >> respective library component to evolve freely and allow the >> individuals developing each to decide how to handle deprecations, API >> changes, etc., as we have up until this point. The project is still >> very much in "innovation mode" across the board, but some parts may >> grow more conservative than others. Having roughly time-based releases >> encourages everyone to be ready-to-release at any given time, and we >> develop a steady cadence of getting new functionality and >> improvements/fixes out the door. >> >> On Fri, Jun 7, 2019 at 1:25 PM Antoine Pitrou <anto...@python.org> wrote: >> > >> > >> > I think there's a marketing merit to issuing a 1.0.0 release. >> > >> > Regards >> > >> > Antoine. >> > >> > >> > Le 07/06/2019 à 20:05, Wes McKinney a écrit : >> > > So one idea is that we could call the next release 1.14.0. So the >> > > second number is the API version number. This encodes a sequencing of >> > > the evolution of the API. The library APIs are already decoupled from >> > > the binary serialization protocol, so I think we merely have to state >> > > that API changes and protocol changes are not related to each other. >> > > >> > > On Fri, Jun 7, 2019 at 12:58 PM Jacques Nadeau <jacq...@apache.org> >> wrote: >> > >> >> > >> It brings up an interesting point... do we couple the stability of >> the apis >> > >> with the stability of the protocol. If the protocol is stable, we >> should >> > >> start providing guarantees for it. How do we want to express these >> > >> different velocities? >> > >> >> > >> On Fri, Jun 7, 2019 at 10:48 AM Antoine Pitrou <anto...@python.org> >> wrote: >> > >> >> > >>> >> > >>> Le 07/06/2019 à 19:44, Jacques Nadeau a écrit : >> > >>>> On Fri, Jun 7, 2019 at 10:25 AM Antoine Pitrou <anto...@python.org> >> > >>> wrote: >> > >>>> >> > >>>>> Hi Wes, >> > >>>>> >> > >>>>> Le 07/06/2019 à 17:42, Wes McKinney a écrit : >> > >>>>>> >> > >>>>>> I think >> > >>>>>> this would have a lot of benefits for project onlookers to remove >> > >>>>>> various warnings around the codebase around stability and cautions >> > >>>>>> against persistence of protocol data. It's fair to say that if we >> _do_ >> > >>>>>> make changes in the future, that there will be a transition path >> for >> > >>>>>> migrate persisted data, should it ever come to that. >> > >>>>> >> > >>>>> I think that's a good idea, but perhaps the stability promise >> shouldn't >> > >>>>> cover the Flight protocol yet? >> > >>>> >> > >>>> Agreed. >> > >>>> >> > >>>>>> I would suggest a "1.0.0" release either as our next release >> (instead >> > >>>>>> of 0.14.0) or the release right after that (if we need more time >> to >> > >>>>>> get affairs in order), with the guidance for users of: >> > >>>>> >> > >>>>> I think we should first do a regular 0.14.0 with all that's on our >> plate >> > >>>>> right now, then work towards a 1.0.0 as the release following that. >> > >>>> >> > >>>> What is different from your perspective? If the protocol hasn't >> changed >> > >>> in >> > >>>> over a year, why not call it 1.0? >> > >>> >> > >>> I would say that perhaps some API cleanup is in order. Remove >> > >>> deprecated ones, review experimental APIs, perhaps mark experimental >> > >>> certain APIs that we forgot to... >> > >>> >> > >>> Regards >> > >>> >> > >>> Antoine. >> > >>> >>
