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. > >> > >>> > >>
