Thanks Kou for volunteering to be the release manager. I can't imagine there are any objections :)
As this is my first release with the project, I'm eager to learn how things work and to help however I can. One thing that occurs to me is the management of the backlog for 0.14 and the release-readiness of each of the languages and subprojects. Like Kou just did here for the release as a whole, do individuals stand up and volunteer to oversee an individual language/component? It seems unreasonable to expect one release manager to know that all 11 languages are in good condition, have no critical issues outstanding, and that all build artifacts (binaries, docs) build correctly; and the project seems too large to assume that the work will just get done on its own. I gather that this has all been done informally in the past, but would some folks be interested in taking up this release-prep role for the various languages and formalizing that responsibility a bit? By "formalize" I just mean write down on the wiki ( https://cwiki.apache.org/confluence/display/ARROW/Arrow+0.14.0+Release) who is overseeing the release for each language and what the current status is. That way, Kou and anyone else can see at a glance which subprojects are ready for release and who to talk to about wrangling the others. For my part, I've been curating the R backlog and 0.14 release scope and working with Romain and others to get the essentials done, and I'd be happy to record that I'm doing this and publicize when the key issues have been addressed and we're ready to release. If different people were to do that for the other 10 languages, we could eliminate some ambiguity as to what the status is and who is taking responsibility for ensuring that the necessary work gets done. Thoughts? Neal On Wed, Jun 12, 2019 at 10:05 PM Sutou Kouhei <k...@clear-code.com> wrote: > 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. > >> > >> > >>> > >> > >> > >> >
