You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rafael Schloming <rh...@alum.mit.edu> on 2015/03/02 20:07:13 UTC
0.9 release schedule
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.
Please plan any work you're doing accordingly, it would be good to get 0.9
closed down quickly.
FYI, I am currently traveling, so I'll only be online intermittently over
the next two weeks. I will be checking in next week though and assuming
there are no issues, I will spin the release as soon as Andrew's work has
landed.
--Rafael
Re: 0.9 release schedule
Posted by Ken Giusti <kg...@redhat.com>.
----- Original Message -----
> From: "Rafael Schloming" <rh...@alum.mit.edu>
> To: proton@qpid.apache.org
> Cc: users@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 <ac...@redhat.com> wrote:
>
> > On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> > >
> > > ----- Original Message -----
> > > > From: "Andrew Stitcher" <as...@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
Re: 0.9 release schedule
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2015-03-09 at 06:56 -0400, Rafael Schloming wrote:
> 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.
Big +1. Hopefully the new reactor APIs will hit that mark in the next
release or two once people have started to use them and shake out the
wrinkles.
>
> 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.
Another big +1. That is greatly preferable to dragging out the release
process while we wait for unreleased API's to "stabilize".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.9 release schedule
Posted by Ken Giusti <kg...@redhat.com>.
----- Original Message -----
> From: "Rafael Schloming" <rh...@alum.mit.edu>
> To: proton@qpid.apache.org
> Cc: users@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 <ac...@redhat.com> wrote:
>
> > On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> > >
> > > ----- Original Message -----
> > > > From: "Andrew Stitcher" <as...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.9 release schedule
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2015-03-09 at 06:56 -0400, Rafael Schloming wrote:
> 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.
Big +1. Hopefully the new reactor APIs will hit that mark in the next
release or two once people have started to use them and shake out the
wrinkles.
>
> 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.
Another big +1. That is greatly preferable to dragging out the release
process while we wait for unreleased API's to "stabilize".
Re: 0.9 release schedule
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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 <ac...@redhat.com> wrote:
> On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> >
> > ----- Original Message -----
> > > From: "Andrew Stitcher" <as...@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.
>
>
Re: 0.9 release schedule
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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 <ac...@redhat.com> wrote:
> On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
> >
> > ----- Original Message -----
> > > From: "Andrew Stitcher" <as...@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.
>
>
Re: 0.9 release schedule
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
>
> ----- Original Message -----
> > From: "Andrew Stitcher" <as...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.9 release schedule
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2015-03-06 at 08:50 -0500, Ken Giusti wrote:
>
> ----- Original Message -----
> > From: "Andrew Stitcher" <as...@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.
Re: 0.9 release schedule
Posted by Ken Giusti <kg...@redhat.com>.
----- Original Message -----
> From: "Andrew Stitcher" <as...@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...
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.9 release schedule
Posted by Gordon Sim <gs...@redhat.com>.
On 03/03/2015 01:46 AM, Andrew Stitcher wrote:
> 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.
To be confident enough to guarantee stability, I think an API needs to
be well understood and have been used for a reasonably wide range of
intended scenarios.
From the thread on the wiki, it sounds like the proposed API is still
changing. There are also some aspects not yet implemented which may
impact the API. I know I am still trying to get my head around all the
implications and without wanting to impute my slowness to anyone else,
there may be some who have not yet read the details.
If this was something entirely new - purely an additive change - then
this might not be a big deal and getting it released would allow for
even wider review. However, for changes, which may impact other code, it
seems risky to squeeze it in while aiming for an RC next week.
One thing I think would help would be some examples, even just code
snippets, showing how the API would be used in various different
scenarios (including e.g. explicit EXTERNAL SASL over SSL, DIGEST-MD5
authentication with no encryption - max ssf 0 -etc).
Re: 0.9 release schedule
Posted by Ken Giusti <kg...@redhat.com>.
----- Original Message -----
> From: "Andrew Stitcher" <as...@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...
--
-K
Re: 0.9 release schedule
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2015-03-02 at 20:46 -0500, Andrew Stitcher wrote:
> 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.
I'm inclined to vote with Gordon. I know 0.9 was "supposed to be" API
stable, but if we are not there already (and it seems we are not) then I
think we are better off getting a release out there so users that are
desperately waiting for the reactive API (e.g. dispatch) can stop
juggling pre-alphas.
Having a 0.9 soon that is not fully API stable, followed shortly by an
0.10 that has a well tested transport API, is IMO much better than
stumbling along with no release at all for an extended period and then
releasing a rushed transport API that we may have to change again
anyway.
Re: 0.9 release schedule
Posted by Andrew Stitcher <as...@redhat.com>.
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
Re: 0.9 release schedule
Posted by Gordon Sim <gs...@redhat.com>.
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.