This release is very important for the project as everyone has done so much good work since M1 and it is precisely why we need to get a good M2 release done before we have a quite period whilst we sort out our position for 0-9 and 0-10. I am not against the release in any way I think we need to do this release it is just important to scope it correctly and ensure we manage it well as a divided community cannot progress as fast as one that is fully behind the trunk.
It would be good to learn from the current difficulties that are being faced with the maintaining two versions of our code base so that we can all focus on driving Qpid forward as a whole. My understanding of the interop that we were after was more than just being able to send simple messages between clients. If that is minimum level we wish to support with this release then that is a much more manageable task. Which is totally possible in the next few days which won't hold up our 0.9 merge so we can push on to 0.10. Do we want interop to go beyond sending simple messages between clients to supporting something like the JMS Message types across all clients? -- Martin On 07/03/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
I share your concerns, but take the opposite view - i.e. +1 for the release. I think if we do not have a release now, we will be unable to release again for some time due to the immense amount of changes that we need to put in for the upcoming AMQP 0-10 spec, and for introducing clustering and other capabilities across the two brokers. For that reason I say we should attempt the following: Define a point in the very near future (5 days or less) when we cut the branch for M2. The minimum interoperability for me is that Java, .NET, C++ and Python can all talk through the released brokers (preferably both C++ and Java) to other clients using basic AMQP functionaliy. I don't think other clients should need to support the extended field types, except in as much as we want those clients to be able to communicate to a Java client. I think we already have the C# and C++ clients in the necessary state for that - or if not, then very close. I'm also happy to release the Python and Ruby (if the latter is anything like ready) but including a notice as to the interoperability limitations - in particular you cannot send certain types of data from the JMS implementation to these clients (as it requires the extended field table). Your concern that "The main development work should occur on trunk. Otherwise we will end up splitting our community into those working on M2-Interop-fixes and those working on 0.9." Is actually what has brought us to this point. Currently a large number of developers (possibly a majority) are working on 0-9 branch, while the rest of us are working on trunk. We need to sunch these up, and concentrate our efforts. -- Rob On 07/03/07, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > From Marnie > > We have quite a bit of work to consider/do prior to release including > > interop testing, docs etc. Happy to raise JIRAs (or assist the release > > manager) for an M2 set of tasks if we proceed. > > From Alan > > ll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you > > ow of any outstanding issues. The plan is to merge python first for > > the tests (branch python speaks both old & new protocols) then the C++ > > codebase. > > I'm concerned about the timing of these events. If we are to perform > an M2 release whose focus is Interop between the various components > then we should be specify which components and ensuring they interop. > BEFORE we branch and therefore before we merge any 0.9 work to trunk. > The main development work should occur on trunk. Otherwise we will end > up splitting our community into those working on M2-Interop-fixes and > those working on 0.9. > > How are we supposed to merge changes that occur between the two > branches? I always thought that when we branched for a release only > the smallest bug fix changes should be merged (At the release managers > discretion) If the trunk isn't at the point to release then we > shouldn't branch. > > My current concerns that I'd like to address on the list are: > > - The scope of interop language requirements. Java->.Net is ok AFAIK > but what about C++,Python,Ruby. Esp. given the non-standard field > table in the java client. > > - Where development will occur. > > - How the 0.9 merge will effect this development process. > > I think the discussion the discussion around scoping for M2 needs more > work so that we all have a clear view of what needs to be done before > we can perform release. > > Until these things have been cleared up I feel as though I should -1 the > release > > [ -1 ] M2 Release inc Java, C++, .NET > [ -1 ] Python and Ruby clients > > -- > Martin Ritchie >
