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
