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