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 Fri, 06 Mar 2015 16:58:01 GMT
On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> 
> ----- 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...
> 


Hear hear! This is still a young and evolving project, we need to
release our developments *quickly* so real developers can use them and
tell us how they need fixing. We are now in SEVERE feature-creep mode
with this release. Dispatch is dependent on unreleased features and is
suffering as a consequence. I am sure there are others in the same boat.
It is not good to make early adopters suffer! Lets release what we have
now, and then do another release *quickly* for things that are not yet
finished but are important  (e.g. the transport changes).

Apart from being a problem for users, slow releases make developers want
to stuff all their new work into the current release because they fear
there won't be another release for ages, and it becomes a
self-fulfilling prophecy. Lets nip this in the bud and get back to a
healthy schedule of regular, rapid releases.

Cheers,
Alan.


Mime
View raw message