Sounds good. On Mon, Jun 10, 2019 at 11:06 AM Wes McKinney <wesmck...@gmail.com> wrote:
> Hi all, > > OK, it sounds like there is reasonable consensus behind the plan: > > * Make a 0.14.0 release in the near future (later this month?) > * Publicize that the next release will be 1.0.0, in a "speak now or > hold your peace" fashion > * Release 1.0.0 as following release. I would suggest not waiting too > long, so late August / early September time frame > > I'm going to continue grooming the 0.14.0 backlog to help refine the > scope of what still needs to be done for C++/Python to get the next > release out. If the stakeholders in various project subcomponents > could also groom the backlog and mark any blockers, that would be very > helpful. > > I suggest shooting for a release candidate for 0.14.0 either the week > of June 24 or July 1 (depending on where things stand) > > Thanks > Wes > > On Mon, Jun 10, 2019 at 2:39 AM Sutou Kouhei <k...@clear-code.com> wrote: > > > > 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. > > >> > >>> > > >> >
