----- Original Message -----
> From: "Andrew Stitcher" <astitc...@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...


Reply via email to