I know this is probably not the place, but it looks like more contributions are being found in the transport proposals for AMQP's next revision. Its important that's right, and undoubtedly some prototyping work will have to be done on some code *branch* to test the concepts.
I'm kind of thinking that any transport changes should be targetted at whatever release is the start of HA, since the killer features of the revised transport are better support for HA. That might be M4. If I understand Rob, persistence is looking pretty good. So an M2 for Christmas might be worth just persistence and Maven. Nailing JMS might be a long piece of string depending on how TCK testing goes. I wouldn't bet on that for Christmas. M1 - something that works M2 - works with persistence, builds purdy M3 - JMS'ified, perhaps protocol changes M4 - HA Being good first, then being great gets my vote. HA should be a cut all of its own, and we should have a solid conceptual foundation before going there. HA will expose any weaknesses in the protocol and in Qpid very quickly. John On 14/11/06, Steve Vinoski <[EMAIL PROTECTED]> wrote:
On Nov 14, 2006, at 3:42 PM, Robert Greig wrote: > On 14/11/06, Carl Trieloff <[EMAIL PROTECTED]> wrote: > >> To this end my a propose a third option: >> - branch to release what we have now (This is a good so that we can >> work through all the apache release procedures) >> - when we release C++ and other components in a few weeks time >> (maybe >> push back to Dec) we call it M2 and re-cut an update of Java >> - with maven + new code generators, persistence etc.... > > This works for me. I was going to propose (after M1 was out of the > way) that M2 was scoped to be maven, persistence and as many JMS > compliance improvements as we could achieve. That would push the major > HA and protocol changes into an M3 in January. I was about to respond with a similar suggestion, but even less aggressive in terms of features. What we'd like to see is an M2 starting essentially right away, shortly after Rajith branches for M1. We'd like to scope M2 to include maven, along with a move to junit3 so as to enhance the effectiveness of maven and enforce the jdk 1.4 constraint for client. What would specifically *not* be in M2, however, would be a move to the new rev of AMQP -- we'd push that off to M3 (note BTW that this requires going through JIRA to move all relevant issues related to AMQP version from M2 to M3). Whether persistence and JMS could be in the picture, I hadn't considered. I don't know how close persistence is, nor how much work the JMS stuff is, but we can certainly talk about that. Like the issue that Marnie and John raised earlier, where a certain party is looking for an M1 based on what's there today, we have other parties looking for a mavenized release very soon based on the current version of AMQP. Hopefully we can all help each other out, rather than arguing and all of us losing as a result. Note that there's nothing that prohibits us from starting an M2 immediately after M1. > I was hoping that we could get that M2 out in December (although > realistically I had thought mid-December). The motivation for that is > that we have a major project that does not require HA but does need > the persistence changes and I imagine their needs are not unique. I like the December target date for M2. However, just be aware that the Apache release process can be long and drawn out. It can take many weeks. For example, Yoko has been trying to get a release out for about the past 10 weeks. It takes a minimum of a 3-day vote in this group followed by a 3-day vote by the incubator PMC to get a release, and pretty much nobody gets it right the first time, meaning that this 6-7 day process usually has to be repeated several times. I would even volunteer to serve as M2 release manager. Thoughts? --steve
