Alan has volunteered to help with the C++ release and Rafi has offered to help with the python/ruby clients. Can Martin volunteer for the java broker/client ? I am not familliar with the M2 releated JIRA's as most of my work has been on branches. So if Martin or Rupert can help sort which JIRA's are priority to M2 and then fix them, I really appreciate that. I see that Marnie has already sorted through the JIRA's.
Can Alan, Rafi and Martin/Rupert update the release page with action items/time frames?? If so then we can start working on the overall release plan/schedule. Regards, Rajith. On 4/19/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
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 >
