Marnie, The current release process (what we did for M1) was more or less the HTTPD release process. Well......maybe we cut a few corners here and there, but I think we did ok. So +1 for following the process properly :)
Rajith On 4/19/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
On 19/04/07, Alan Conway <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-04-19 at 10:44 -0500, Tomas Restrepo wrote: > > If I may offer a humble suggestion here: Could we please first agree on > what > > to release and what may constitute a good reason to plan a release? My > point > > here is that it would be really nice if the entire project was working > > alongside the same plan. Right now we have the C++ code going in one > > direction, the Java code going into a somewhat different direction, the > .NET > > code playing catchup, and I don't even know what the python and ruby > code > > bases are. > > I think that's one of the key goals of the M2 release. M2 represents the > last time all the projects *were* in a consistent interoperable state, > so it's a valuable thing to get out there. > > > For example, it would seem sensible, while the protocol spec is in flux, > to > > align one way or another the project releases with the protocol > releases. > > That is to say, if we define protocol version Y as being of interest to > the > > project, either target it all, or don't target it at all. Otherwise, > getting > > the interop in place just among our different code bases will be too > > painful, not to even speak of interoping with other protocol > > implementations. > > > > Any comments? > > We're in a bit of a discombobulated state right now as you point out. I > would say that M3 (or whatever the next major release is called) should > aim to get us back in sync with all projects on the same major protocol > version. I used to think this would be 0-9, but it looks like we may > have to wait for 0-10. Its not clear now how far away that is, if it > doesn't happen soon we may need to find another way to reconnect the > projects. I'm in two minds about making C++ bilingual 0-8, 0-9 - I'll > wait till after the AMQP FTF and see how far away 0-10 looks before I > reconsider the question. M2 should be "all brokers and clients interoperable at AMQP0-8", plus Java Broker - Java client JMS TCK compatability (requires Qpid "extensions" to AMQP). AMQP0-9 (without the WIP additions) may be very easy to implement and I think that is what OpenAMQ has achieved. However we may not see much value in this. AMQP0-10 will liklely be a fairly major set of changes. As Alan aludes to there is an AMQP face to face meeting next week at which the AMQP working group will try to come to agreements on aspects of 0-10 as well as a scope for 0-11. One of the things I would like to see defined is the degree to which (post 1-0) versions of the protocol may differ within a major release. The amount of change which we will have to accomodate will influence how we design our multi-version support (post 1-0 we should support prior versions to the one we claim to support, prior to 1-0 we are not expected to make that guarantee). -- Rob
