2008/10/8 Aidan Skinner <[EMAIL PROTECTED]>: > On Wed, Oct 8, 2008 at 10:33 AM, Robert Godfrey <[EMAIL PROTECTED]>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,
Yes - because the C++ API follows the AMQP API, as it did between M1 (0-8), M2 (0-9 and 0-9WIP) and M3(0-10 for C++) > the Python and Ruby clients are quite > fast changing, Since they are generated from the AMQP spec. >The .Net client has been totally rewritten for 0-10. There is > no supported lower level API for the Java client at all. Again driven by the AMQP protocol version. What I am saying is that since (other than JMS) we have no protocol independent APIs, the logical point at which the major version number changes should be the point at which Qpid *as a whole* has moved to a new version of the protocol. Further I think that we should as a project strive to make sure that all clients/brokers move to a new version of the protocol *at the same time*. I think the situation we have currently is very poor. If we declare a major version now, then when we move the Java broker to 0-10 the APIs need to work with it necessarily change and we should change the major version number. Until we have consistency on the (protocol) APIs supported by the brokers, we will not have stability in the programming APIs offered by the clients. My view is that the first step to getting to any non-zero major number *has* to be getting all the components to have some common version of AMQP which they all speak. > 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. As above the APIs are driven off the protocol API. This, I think, is a very proper point to have a major version increase. I doubt that there'll be more than 1 or two more major protocol releases this decade. -- Rob
