On 24 March 2011 15:56, Rafael Schloming <[email protected]> wrote: > On 03/24/2011 10:43 AM, Robert Godfrey wrote: > >> So - obviously we need to hear a few more voices on this... But personally >> I'm *really* keen to get the project moving towards AMQP 1-0 ASAP. In my >> spare time I've sort of hacked up an AMQP 1-0 Java client, and then >> spliced >> that onto the Qpid Java Broker... It's not code I would really consider >> putting into Qpid, but this (and the code you've got on github) may be >> able >> to help us bootstrap testing our 1-0 efforts. >> >> If we follow the idea of the common transport, I would guess that the best >> way to progress this is probably to create a branch where we can start out >> defining and implementing this transport as a standalone entity. It >> doesn;t >> seem to make sense to me to have this in trunk and tie it into the release >> cycles of the current Qpid work... >> >> Thoughts? >> > > For developing the transport itself, I'm not sure it matters much whether > we branch or not if we're treating it as an independent component. Obviously > if we start integrating it into other pieces then a branch for those pieces > would be called for. The release cycle question is certainly interesting. I > agree it shouldn't really be tied to the trunk release in one sense, but I > do think it would be good to have something ready for this year's ApacheCon, > and given that it might make sense to have deliverable milestones that > coincide with the trunk releases purely as a means of focusing progress. > > >From a theoretical point of view I agree.
Logically we are starting from a clean slate and developing what amounts to an independent library which we will then, hopefully, make into a dependency of the rest of qpid... Branch is probably the wrong name here... but I'm thinking that this doesn't really fit under the same umbrella as the rest of the components which have a single release cycle currently. What we possibly want is something that is in parallel to the existing codebase... repos/asf/qpid/trunk/transport in parallel to repos/asf/qpid/trunk/qpid would be one way of doing it... Although looking at other Apache projects it seems like the common way of doing this is .../asf/<project>/<component>/trunk or even .../asf/<project>/<component>/<sub-component>/trunk (see ant, commons, httpd, etc.) Though this would obviously require a little more re-organisation for us all... -- Rob
