----- Original Message ----- > From: "Rafael Schloming" <[email protected]> > To: [email protected] > Cc: [email protected] > 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 <[email protected]> wrote: > > > On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote: > > > > > > ----- Original Message ----- > > > > From: "Andrew Stitcher" <[email protected]> > > > > To: [email protected] > > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
