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