qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: 0.9 release schedule
Date Fri, 06 Mar 2015 13:50:30 GMT

----- Original Message -----
> From: "Andrew Stitcher" <astitcher@redhat.com>
> To: proton@qpid.apache.org
> Sent: Monday, March 2, 2015 8:46:10 PM
> Subject: Re: 0.9 release schedule
> 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.
> Andrew

In a general sense, how can we be comfortable introducing an API in a 0.x release, and consider
it "stable"?   Wouldn't it make sense to expose the *completed* API for at least one release
before we propose stabilizing it?  

For example, the reactor API is new in 0.9, but until 0.9 is released I suspect that this
API won't be fully explored by users.  And of course we won't uncover any potential gotchas
with the new API until it has seen some adoption.  At that point we may need to change/enhance
the api.

Seems to me we should get the reactor API out in 0.9, consider it complete, and stabilize
that *portion* of the API for 0.10 - possibly longer given the scope of that API.  The SASL
API would then be a candidate for stabilization in 0.10 - assuming it has been completed in
time - with 0.11 being a realistic target for considering the SASL API stable.

In other words, when the project considers an API to be complete (from the developer's point
of view), then there should be at least one release that contains that API before we consider
it a candidate for stabilization.

Just MHO...


View raw message