qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Qpid M2 Branching / C++ 0.9 Merging
Date Wed, 07 Mar 2007 14:54:50 GMT
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 <ritchiem@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message