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