----- Original Message -----
> From: "Rafael Schloming" <r...@alum.mit.edu>
> To: proton@qpid.apache.org
> Cc: us...@qpid.apache.org
> Sent: Monday, March 9, 2015 6:56:49 AM
> Subject: Re: 0.9 release schedule
> 
> Ok, I'll push out a 0.9 RC ASAP.
> 
> On the general topic of API stability, I think the key measure of
> "stability" that I would personally like to see (be it 0.9 or 0.10) is not
> that we somehow freeze APIs and guarantee to never change them, but rather
> that we change them in ways that are backwards compatible.

Agreed.  Just for the record, I'm not advocating we freeze apis and support 
them indefinitely. :)  I just wanted to clarify my understanding as to when an 
api can reasonably be considered stable.

> This doesn't
> limit us as much as you might think, it just means we need to put in a bit
> more work for certain changes, e.g. start using feature macros. The point
> of 0.9 was to get as many changes out of the way as possible before
> incurring the extra overhead associated with maintaining full backwards
> compatibility.
> 
> Once we are satisfied we can maintain this guarantee, I think we should go
> to 1.0 rather than sticking with the perpetual 0.x theme.
> 
> As for newly introduced APIs, I think once we hit 1.0 we probably need to
> put some process in place around bringing new APIs into the codebase.
> Something that makes it clear to users whether something is at that 1.x
> level or not. 

+1

> --Rafael
> 
> 
> On Fri, Mar 6, 2015 at 11:58 AM, Alan Conway <acon...@redhat.com> wrote:
> 
> > On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> > >
> > > ----- 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...
> > >
> >
> >
> > 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.
> >
> >
> 

-- 
-K

Reply via email to