Merging 0-9 and (Re: [VOTE] Qpid M2 Release)

[Alan Conway <ac...@redhat.com>]

We'll need an M2 release branches to isolate M2 from turbulence caused
by the 0-9 merge. We can defer branching for some components. Here's
what I propose for the parts I'm merging:

spec: should be able to merge to trunk as-is, 0-9 adds new XML files
doesn't modify existing ones.

python: on branch speaks both 0-8 and 0-9, I'll verify it on trunk &
branch before merging and leave the default as 0-8 until we move both
brokers to 0-9 on trunk.

cpp: I'll create an M2 branch for cpp now and then merge 0-9. That's our
fallback position for M2. There are some major reorgs planned on the C++
trunk, we will probably be able to have a bilingual client and merge the
trunk updates back to M2. We haven't been planning on a bilingual broker
but if things come together right it might be a possibility - if not we
can release todays broker for M2.

For interop tests we'll have an interim period of testing 0-8 C++ built
from M2 branch with everything else built from trunk, but that will only
last till the rest of the trunk is up to 0-9 at which point it'll be
straightforward 0-8 on M2 and 0-9 on trunk.

Shout quick with any objections/suggestions.

Cheers,
Alan.

On Tue, 2007-03-06 at 11:41 +0000, Marnie McCormack wrote:
> Hi All,
> 
> I there are now some compelling motivations for releasing an M2.
> 
> I'd like to propose an M2, to include:
> 
> - Java Broker
> - Java Client
> - C++ Broker
> - C++ Client
> - .NET Client
> 
> I can speak with more authority on some areas than others, but here's my
> quick summary of major changes since M1:
> 
> - the Java Client/Broker pass the SUN TCK making our offering in this area
> much more attractive
> - the persistence rework on the Java broker is complete and significantly
> advances the functionality
> - the C++ broker is ready for some real use and should get out there for
> early adopters
> - the C++ client interop has been worked upon/used quite a bit in dev
> - the .NET client has been substantially extended and interop improved
> - and a lot of JIRAs resolved on all front, bugs and improvements
> 
> We also need to introduce a new AMQP protocol version across the board, and
> it makes good sense to get M2 out there before we do this.
> 
> I think we also considered releasing the python and ruby for M1, but there
> were gaps in the docs etc. I'm happy that we should include these in M2,
> assuming someone is willing to contribute the required docs etc (and they
> interop).
> 
> I'd like to structure our initial vote as follows:
> 
> - M2 Release including Java, C++ and .NET
> - Additionally python and ruby
> 
> Let's vote first to get an idea of the consensus and then we can create
> threads on release manager, dates, code freezes etc.
> 
> 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.
> 
> *Votes please :*
> 
> *[ ] M2 Release inc Java, C++, .NET
> [ ] Python and Ruby clients
> 
> *And here is my +1 for all both.
> 
> Regards,
> Marnie

Re: Merging 0-9 and (Re: [VOTE] Qpid M2 Release)

[Alan Conway <ac...@redhat.com>]

On Tue, 2007-03-06 at 16:33 +0000, Rupert Smith wrote:
> Can I request as few branches as possible? Ideally, just the one for
> the entirety of M2. I'm already starting to lose track of what is in
> what branch.

A reasonable request :)

I'll hold off making a branch for C++, I'll merely note the last
revision before merge so that we can branch from it if/when we need to.

Cheers,
Alan.

Re: Merging 0-9 and (Re: [VOTE] Qpid M2 Release)

[Rupert Smith <ru...@googlemail.com>]

Can I request as few branches as possible? Ideally, just the one for
the entirety of M2. I'm already starting to lose track of what is in
what branch.

On 3/6/07, Alan Conway <ac...@redhat.com> wrote:
> We'll need an M2 release branches to isolate M2 from turbulence caused
> by the 0-9 merge. We can defer branching for some components. Here's
> what I propose for the parts I'm merging:
>
> spec: should be able to merge to trunk as-is, 0-9 adds new XML files
> doesn't modify existing ones.
>
> python: on branch speaks both 0-8 and 0-9, I'll verify it on trunk &
> branch before merging and leave the default as 0-8 until we move both
> brokers to 0-9 on trunk.
>
> cpp: I'll create an M2 branch for cpp now and then merge 0-9. That's our
> fallback position for M2. There are some major reorgs planned on the C++
> trunk, we will probably be able to have a bilingual client and merge the
> trunk updates back to M2. We haven't been planning on a bilingual broker
> but if things come together right it might be a possibility - if not we
> can release todays broker for M2.
>
> For interop tests we'll have an interim period of testing 0-8 C++ built
> from M2 branch with everything else built from trunk, but that will only
> last till the rest of the trunk is up to 0-9 at which point it'll be
> straightforward 0-8 on M2 and 0-9 on trunk.
>
> Shout quick with any objections/suggestions.
>
> Cheers,
> Alan.
>
> On Tue, 2007-03-06 at 11:41 +0000, Marnie McCormack wrote:
> > Hi All,
> >
> > I there are now some compelling motivations for releasing an M2.
> >
> > I'd like to propose an M2, to include:
> >
> > - Java Broker
> > - Java Client
> > - C++ Broker
> > - C++ Client
> > - .NET Client
> >
> > I can speak with more authority on some areas than others, but here's my
> > quick summary of major changes since M1:
> >
> > - the Java Client/Broker pass the SUN TCK making our offering in this area
> > much more attractive
> > - the persistence rework on the Java broker is complete and significantly
> > advances the functionality
> > - the C++ broker is ready for some real use and should get out there for
> > early adopters
> > - the C++ client interop has been worked upon/used quite a bit in dev
> > - the .NET client has been substantially extended and interop improved
> > - and a lot of JIRAs resolved on all front, bugs and improvements
> >
> > We also need to introduce a new AMQP protocol version across the board, and
> > it makes good sense to get M2 out there before we do this.
> >
> > I think we also considered releasing the python and ruby for M1, but there
> > were gaps in the docs etc. I'm happy that we should include these in M2,
> > assuming someone is willing to contribute the required docs etc (and they
> > interop).
> >
> > I'd like to structure our initial vote as follows:
> >
> > - M2 Release including Java, C++ and .NET
> > - Additionally python and ruby
> >
> > Let's vote first to get an idea of the consensus and then we can create
> > threads on release manager, dates, code freezes etc.
> >
> > 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.
> >
> > *Votes please :*
> >
> > *[ ] M2 Release inc Java, C++, .NET
> > [ ] Python and Ruby clients
> >
> > *And here is my +1 for all both.
> >
> > Regards,
> > Marnie
>
>