qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Qpid M2 Branching / C++ 0.9 Merging
Date Wed, 07 Mar 2007 14:41:56 GMT
>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

View raw message