Hi All, Playing slight catch up, apologies.
So, a few comments on the various posts on this thread .... 1. Completely agree with Alan & Rob's comment on the goal of M2 being 0-8 interop, as far as we can manage it ! I think we should correctly have modest goals for M2 and not seek to make it perfrect, but a useful milestone release which gets hitherto unreleased components out there and provides a good build for users, far more feature rich than M1 ! 2. Re Rajith's point about M1 being fairly close to the HTTPD process - yes, and wasn't my intent to make any major changes just to get our approach doc'd in the interests of transparency for everyone and to move our project forward in incubation terms ! If no-one objects, I'll create a starter release process page with something pretty close to the HTTPD docs tomorrow and people can discuss/edit as we go along ? 3. Tomas - hoping you saw the vote thread which has a summary of the components we voted to release for M2 ? Personally (my fault) I doubt we really want to put Ruby out there (for maturity reasons) but the votes were in favour so had to go with that. (We can perhaps revisit if we find it problematic as we go along building M2). 4. Java JIRAs for M2 - I have reviewed all the Java JIRAs marked as for M2 and thus far only left in scope those that need doing (have discussed with the reporters/assignees as I went along where not clear). Happy for people to review and amend if anyone disagrees with my assessments though :-) Phew. All that and chicken pox in our house this week :-( Anyhow, more tomorrow ! Regards, Marnie On 4/20/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
On 19/04/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > 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 I should have some time to do that now. -- Martin Ritchie
