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