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. 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.

--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.
>
>

Reply via email to