qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: 0.9 release schedule
Date Thu, 05 Mar 2015 23:15:11 GMT
On Mon, 2015-03-02 at 20:46 -0500, Andrew Stitcher wrote:
> On Mon, 2015-03-02 at 20:00 +0000, Gordon Sim wrote:
> > On 03/02/2015 07:07 PM, Rafael Schloming wrote:
> > > Hi Everyone,
> > >
> > > I'd like to propose spinning the first beta (or possibly just RC) for 0.9
> > > sometime next week. We've been using alphas to get some early eyes on some
> > > of the new APIs in this release. I think when Andrew's SASL work lands
> > > there will be no remaining work for 0.9 in the category of major API
> > > changes/improvements. That should hopefully put us in a position to quickly
> > > test and stabilize things and get 0.9 out the door.
> > 
> > The 0.9 release was originally scheduled for the end of 2014. We've had 
> > three alphas already. To me, its already too late in the cycle for 
> > 'major API changes/improvements'.
> > 
> > As mentioned on the other thread, in my opinion it would be better to 
> > land Andrew's work during 0.10 allowing for less rushed review, 
> > evaluation and testing.
> I'm happy to let the new API work be more carefully reviewed. The only
> reason to me to get it in 0.9 is that 0.9 was intended to be a point for
> API stability from then on. And the transport API is a significant
> change in the engine API. Pushing it off means allowing 0.10 to break
> API compatibility.

I'm inclined to vote with Gordon. I know 0.9 was "supposed to be" API
stable, but if we are not there already (and it seems we are not) then I
think we are better off getting a release out there so users that are
desperately waiting for the reactive API (e.g. dispatch) can stop
juggling pre-alphas.

Having a 0.9 soon that is not fully API stable, followed shortly by an
0.10 that has a well tested transport API, is IMO much better than
stumbling along with no release at all for an extended period and then
releasing a rushed transport API that we may have to change again

View raw message