Hi, I like the plan too.
If nobody wants be a release manager for 0.14.0, I can be a release manager. I'm busy recently but I'll be able to make time from June 24. Thanks, -- kou In <CAKa9qDnU-fYk7z-FdQS_SDaH3qg7ciVjr4_OKvqXWioiZ2=Z=g...@mail.gmail.com> "Re: [DISCUSS] Timing of release and making a 1.0.0 release marking Arrow protocol stability" on Mon, 10 Jun 2019 14:19:51 -0700, Jacques Nadeau <jacq...@apache.org> wrote: > 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. >> > >> > >>> >> > >> >>
