qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: M4 versioning and release management
Date Wed, 08 Oct 2008 09:49:28 GMT
On Wed, Oct 8, 2008 at 10:33 AM, Robert Godfrey <rob.j.godfrey@gmail.com>wrote:


> I think the real issue for me is that not all clients/brokers are
> currently speaking the same version of AMQP; so we have API
> inconsistency within the project.  If everything were speaking
> AMQP0-10 then I would be fine in moving to a 1.x.  If the version of
> AMQP then moves forward, and the derived APIs change then, as per the
> Apache guidelines linked to by Aidan, we can change the major version
> number.


Having everything speak 0-10 would be good, but is unrelated to having a
stable API.

The protocol version may drive some changes, but there's a lot of churn in
the C++ API between M1, M2 and M3, the Python and Ruby clients are quite
fast changing, The .Net client has been totally rewritten for 0-10. There is
no supported lower level API for the Java client at all.

I do agree with Robert that we have enough maturity and existing users
> to justify a non 0.x version numbering.  Skipping from 0.3 to 1.4
> without ever having a 1.0 would seem somewhat odd to me though :-)
>

A non 0.x version number isn't about being production ready, and it
certainly isn't about existing users. It's about making a statement about
the stability of the APIs that we're shipping and an implicit promise that
it won't churn that often.

If we go to 1.x, the next release will almost certainly have to be 2.x and
then 3.x and 4.x etc. until we stabilise the APIs. We'd end up shipping Qpid
10.something before it settled down.

- Aidan

-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message