You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Keith W <ke...@gmail.com> on 2015/01/09 10:34:57 UTC
Re: Any ETA on a QPid 0.32 release
Hi all,
Looking through this thread, it is not clear that we came to a settled
position for release numbering, and when exactly we'd would move to
releasing components independently. On the java side we are getting to a
position where a release soon would be sensible. How best do we go
forward?
I'll be ready to put in some time helping plan/make the changes to the
release system happen, once we agree what that direction should be.
Kind regards, Keith.
On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
wrote:
> In addition to [point] releases not actually occuring at the time the
> version suggests, for me another downside of using the Year.Month
> approach is that it doesnt as clearly convey a sense of impact for the
> changes involved in the release, i.e is it a major or minor release,
> are there any compatibility considerations etc. It might for a bugfix
> release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
> majorly different than 15.12 or not, given it might have nearly 2
> months of changes in it, or possibly just days? If it isnt,
> could/should it have been labeled 15.12.1 instead (at which point,
> back to that naming vs timing issue)? Obviously we dont convey that
> sort of information with the current versions, but it would be nice to
> start.
>
> The major example of Year.Month naming that springs to mind for me is
> Ubuntu, which isnt really quite the same situations since their
> releases are mostly a distribution of other components, whicht are all
> versioned independently and can often be updated to an extent between
> the containing Year.Month distribution releases. I can't immediately
> think of seeing any Apache projects using it as a convention, but I
> assume there are some.
>
> Robbie
>
> On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com> wrote:
> > Agreed - we'd use target date.
> >
> > To Robbie's earlier comment on point releases, we (Java side) might then
> > subsequently release a 15.1.1 as a bugfix release of 15.1, where the next
> > scheduled release would be a 15.5 or whatever (ideally on the java side I
> > think we'd like to move to more frequent releases, but that's a separate
> > issue).
> >
> > -- Rob
> >
> > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
> >
> >> On 12/03/2014 11:02 AM, Justin Ross wrote:
> >>
> >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com> wrote:
> >>>
> >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
> >>>>
> >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at this
> >>>>>
> >>>>>> point is meaningless and even perhaps confusing. They are both well
> >>>>>> past
> >>>>>> that really, placing a high priority on stability and backward
> >>>>>> compatibility. The 1.0 label to me is more appropriate for newer
> >>>>>> components like proton, dispatch-router and the new JMS client.
> >>>>>>
> >>>>>>
> >>>>> There's a certain appeal to having the version number be the
> year.month
> >>>>> that the product was branched especially if we have four or five
> >>>>> closely related products. If some whizzy feature of the broker
> >>>>> is released in 15.4 then you know that it probably isn't supported in
> >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2 and
> >>>>> dispatch is 1.1.
> >>>>>
> >>>>>
> >>>> Yes, I can see the value in being able to easily determine ordering
> >>>> between release numbers of components on different schedules. Also, it
> >>>> may
> >>>> help force a more public schedule, by setting the target date in
> order to
> >>>> determine the next release number.
> >>>>
> >>>
> >>>
> >>> I like the idea, but I think it would be "unstable". During the
> release
> >>> process, we'd have to talk about 15.next or something like that because
> >>> it's too hard to know exactly which month we will finish. "3.2" would
> be
> >>> easier to talk about with precision.
> >>>
> >>
> >> I think you would use the target date, not the actual date. So 15.1
> might
> >> actually not be ready until february, but you wouldn't change the
> release
> >> number. Otherwise I would agree with you it would be too fluid.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Use of qpid rather than RabbitMQ in openstack
Posted by Gordon Sim <gs...@redhat.com>.
On 01/28/2015 03:09 PM, Francois Menard wrote:
> Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
No. Decisions about OpenStack should really be discussed in the
OpenStack community, but as someone from the Qpid community who has
spent a little time on an alternate 'driver' (along with Ken Giusti,
also of Qpid), I can say that the intent is not to obsolete anything,
but rather to open new possibilities (through AMQP 1.0).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Use of qpid rather than RabbitMQ in openstack
Posted by Ted Ross <tr...@redhat.com>.
On 01/28/2015 10:09 AM, Francois Menard wrote:
> Folks,
>
> Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
Like Gordon said, The OpenStack community will use whatever messaging
solution that they decide meets their needs.
That said, several of us are working on a hybrid brokered/brokerless
messaging bus based on Qpid Dispatch Router and qpidd that will likely
provide scale, performance, and operational benefits for OpenStack's
oslo.messaging.
I'm finishing up a new feature in Dispatch to allow AMQP endpoints to
transparently access a broker through a network of routers
(https://issues.apache.org/jira/browse/DISPATCH-6). This feature is
needed for the store-and-forward of event notifications. Dispatch
Router already provides the direct message delivery which is appropriate
for RPC patterns.
-Ted
>
> F.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Use of qpid rather than RabbitMQ in openstack
Posted by Francois Menard <fr...@menards.ca>.
Folks,
Is there any intent on qpid obsoleting use of RabiitMQ in openstack ?
F.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Any ETA on a QPid 0.32 release
Posted by Keith W <ke...@gmail.com>.
Justin,
That all sounds sensible to me.
Once the 0.32 cross-component release is done, I am happy to take on the
release manager role of the Java components.
cheers, Keith
On 27 January 2015 at 17:21, Justin Ross <ju...@gmail.com> wrote:
> Based on what we've discussed so far, here's what I propose:
>
> We prepare one more cross-component Qpid release, 0.32. This time, the
> components share a version number and a source branch. Next time they
> won't.
>
> I'll manage the C++, Python, and related components. I will leave the
> Java component to Keith or whoever elects to take it on.
>
> After we branch for Beta, we'll start to reorganize the source tree for
> independent releases.
>
> For reasons of continuity, the next C++ and Python releases will use the
> version number "33", without the leading "0.".
>
> For 0.32, I'd like to try to stick with the schedule I posted earlier: end
> of this month for Alpha, and middle of February for Beta.
>
> Justin
>
> On Tue, Jan 27, 2015 at 5:46 AM, Rob Godfrey <ro...@gmail.com>
> wrote:
>
>> I strongly agree with Keith that any change to the source tree should
>> happen (immediately) after (branching for) the next release. We can have
>> separate people managing the different components if we like, but I think
>> for this release we would be looking at a single release date and running
>> the existing release scripts. After this release we can work out exactly
>> how we want to release each component separately.
>>
>> In terms of numbering, I'm relatively relaxed as to whether we change now
>> or at the next release - I don't think the two changes have to be
>> coincident.
>>
>> As an aside, in terms of release numbering, somewhat coincidentally this
>> will be (if I have calculated this correctly) the 15th release of Qpid
>> since graduation (the first release was 0.5, then 0.6 and thereafter we
>> always incremented by 0.2), so calling this release 15.1 (as the first
>> release after an arbitrary rebasing of the version numbers) would be fine
>> by me :-)
>>
>> -- Rob
>>
>> On 23 January 2015 at 15:54, Keith W <ke...@gmail.com> wrote:
>>
>>> Hi Justin
>>>
>>> I'm in agreement with the plan to reorganise the source tree in the way
>>> you
>>> describe (and expect that we would want a similar change for java) but
>>> am I
>>> concerned about the timing of such a big change. We should be
>>> reorganising trunk just *after* a release branch to give us plenty of
>>> time
>>> to work through the inevitable unexpected consequences properly.
>>>
>>> I am in favour of having one more qpid-wide release (and I would suggest
>>> we
>>> stick with our existing numbering scheme i.e. 0.32), then split the
>>> source
>>> tree and adopt the new numbering convention for the next -modular-
>>> releases.
>>>
>>> Thoughts?
>>>
>>> cheers, Keith.
>>>
>>>
>>>
>>>
>>> On 21 January 2015 at 12:35, Justin Ross <ju...@gmail.com> wrote:
>>>
>>> > Hi, Keith.
>>> >
>>> > Apart from picking an approach for version numbers, I don't think
>>> there is
>>> > anything that should prevent you from starting an independent Java
>>> release.
>>> >
>>> > I've put some of my thoughts regarding source-tree organization down in
>>> > the wiki. Please feel free to add your own.
>>> >
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
>>> >
>>> > Whatever we decide on, we don't have to do it all at once in a big
>>> bang.
>>> > We can incrementally move modules into a new structure.
>>> >
>>> > Justin
>>> >
>>> >
>>> > On Fri, Jan 9, 2015 at 4:34 AM, Keith W <ke...@gmail.com> wrote:
>>> >
>>> >> Hi all,
>>> >>
>>> >> Looking through this thread, it is not clear that we came to a settled
>>> >> position for release numbering, and when exactly we'd would move to
>>> >> releasing components independently. On the java side we are getting
>>> to a
>>> >> position where a release soon would be sensible. How best do we go
>>> >> forward?
>>> >>
>>> >> I'll be ready to put in some time helping plan/make the changes to the
>>> >> release system happen, once we agree what that direction should be.
>>> >>
>>> >> Kind regards, Keith.
>>> >>
>>> >>
>>> >>
>>> >> On 3 December 2014 at 15:15, Robbie Gemmell <robbie.gemmell@gmail.com
>>> >
>>> >> wrote:
>>> >>
>>> >> > In addition to [point] releases not actually occuring at the time
>>> the
>>> >> > version suggests, for me another downside of using the Year.Month
>>> >> > approach is that it doesnt as clearly convey a sense of impact for
>>> the
>>> >> > changes involved in the release, i.e is it a major or minor release,
>>> >> > are there any compatibility considerations etc. It might for a
>>> bugfix
>>> >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
>>> >> > majorly different than 15.12 or not, given it might have nearly 2
>>> >> > months of changes in it, or possibly just days? If it isnt,
>>> >> > could/should it have been labeled 15.12.1 instead (at which point,
>>> >> > back to that naming vs timing issue)? Obviously we dont convey that
>>> >> > sort of information with the current versions, but it would be nice
>>> to
>>> >> > start.
>>> >> >
>>> >> > The major example of Year.Month naming that springs to mind for me
>>> is
>>> >> > Ubuntu, which isnt really quite the same situations since their
>>> >> > releases are mostly a distribution of other components, whicht are
>>> all
>>> >> > versioned independently and can often be updated to an extent
>>> between
>>> >> > the containing Year.Month distribution releases. I can't immediately
>>> >> > think of seeing any Apache projects using it as a convention, but I
>>> >> > assume there are some.
>>> >> >
>>> >> > Robbie
>>> >> >
>>> >> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
>>> >> wrote:
>>> >> > > Agreed - we'd use target date.
>>> >> > >
>>> >> > > To Robbie's earlier comment on point releases, we (Java side)
>>> might
>>> >> then
>>> >> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where
>>> the
>>> >> next
>>> >> > > scheduled release would be a 15.5 or whatever (ideally on the java
>>> >> side I
>>> >> > > think we'd like to move to more frequent releases, but that's a
>>> >> separate
>>> >> > > issue).
>>> >> > >
>>> >> > > -- Rob
>>> >> > >
>>> >> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
>>> >> > >
>>> >> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
>>> >> > >>
>>> >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com>
>>> wrote:
>>> >> > >>>
>>> >> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
>>> >> > >>>>
>>> >> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at
>>> >> this
>>> >> > >>>>>
>>> >> > >>>>>> point is meaningless and even perhaps confusing. They are
>>> both
>>> >> well
>>> >> > >>>>>> past
>>> >> > >>>>>> that really, placing a high priority on stability and
>>> backward
>>> >> > >>>>>> compatibility. The 1.0 label to me is more appropriate for
>>> newer
>>> >> > >>>>>> components like proton, dispatch-router and the new JMS
>>> client.
>>> >> > >>>>>>
>>> >> > >>>>>>
>>> >> > >>>>> There's a certain appeal to having the version number be the
>>> >> > year.month
>>> >> > >>>>> that the product was branched especially if we have four or
>>> five
>>> >> > >>>>> closely related products. If some whizzy feature of the broker
>>> >> > >>>>> is released in 15.4 then you know that it probably isn't
>>> >> supported in
>>> >> > >>>>> dispatch 15.2. There's no way to know that if the broker is
>>> 3.2
>>> >> and
>>> >> > >>>>> dispatch is 1.1.
>>> >> > >>>>>
>>> >> > >>>>>
>>> >> > >>>> Yes, I can see the value in being able to easily determine
>>> ordering
>>> >> > >>>> between release numbers of components on different schedules.
>>> >> Also, it
>>> >> > >>>> may
>>> >> > >>>> help force a more public schedule, by setting the target date
>>> in
>>> >> > order to
>>> >> > >>>> determine the next release number.
>>> >> > >>>>
>>> >> > >>>
>>> >> > >>>
>>> >> > >>> I like the idea, but I think it would be "unstable". During the
>>> >> > release
>>> >> > >>> process, we'd have to talk about 15.next or something like that
>>> >> because
>>> >> > >>> it's too hard to know exactly which month we will finish. "3.2"
>>> >> would
>>> >> > be
>>> >> > >>> easier to talk about with precision.
>>> >> > >>>
>>> >> > >>
>>> >> > >> I think you would use the target date, not the actual date. So
>>> 15.1
>>> >> > might
>>> >> > >> actually not be ready until february, but you wouldn't change the
>>> >> > release
>>> >> > >> number. Otherwise I would agree with you it would be too fluid.
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> ---------------------------------------------------------------------
>>> >> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > >> For additional commands, e-mail: users-help@qpid.apache.org
>>> >> > >>
>>> >> > >>
>>> >> >
>>> >> >
>>> ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>
Re: Any ETA on a QPid 0.32 release
Posted by Justin Ross <ju...@gmail.com>.
Based on what we've discussed so far, here's what I propose:
We prepare one more cross-component Qpid release, 0.32. This time, the
components share a version number and a source branch. Next time they
won't.
I'll manage the C++, Python, and related components. I will leave the Java
component to Keith or whoever elects to take it on.
After we branch for Beta, we'll start to reorganize the source tree for
independent releases.
For reasons of continuity, the next C++ and Python releases will use the
version number "33", without the leading "0.".
For 0.32, I'd like to try to stick with the schedule I posted earlier: end
of this month for Alpha, and middle of February for Beta.
Justin
On Tue, Jan 27, 2015 at 5:46 AM, Rob Godfrey <ro...@gmail.com>
wrote:
> I strongly agree with Keith that any change to the source tree should
> happen (immediately) after (branching for) the next release. We can have
> separate people managing the different components if we like, but I think
> for this release we would be looking at a single release date and running
> the existing release scripts. After this release we can work out exactly
> how we want to release each component separately.
>
> In terms of numbering, I'm relatively relaxed as to whether we change now
> or at the next release - I don't think the two changes have to be
> coincident.
>
> As an aside, in terms of release numbering, somewhat coincidentally this
> will be (if I have calculated this correctly) the 15th release of Qpid
> since graduation (the first release was 0.5, then 0.6 and thereafter we
> always incremented by 0.2), so calling this release 15.1 (as the first
> release after an arbitrary rebasing of the version numbers) would be fine
> by me :-)
>
> -- Rob
>
> On 23 January 2015 at 15:54, Keith W <ke...@gmail.com> wrote:
>
>> Hi Justin
>>
>> I'm in agreement with the plan to reorganise the source tree in the way
>> you
>> describe (and expect that we would want a similar change for java) but am
>> I
>> concerned about the timing of such a big change. We should be
>> reorganising trunk just *after* a release branch to give us plenty of time
>> to work through the inevitable unexpected consequences properly.
>>
>> I am in favour of having one more qpid-wide release (and I would suggest
>> we
>> stick with our existing numbering scheme i.e. 0.32), then split the source
>> tree and adopt the new numbering convention for the next -modular-
>> releases.
>>
>> Thoughts?
>>
>> cheers, Keith.
>>
>>
>>
>>
>> On 21 January 2015 at 12:35, Justin Ross <ju...@gmail.com> wrote:
>>
>> > Hi, Keith.
>> >
>> > Apart from picking an approach for version numbers, I don't think there
>> is
>> > anything that should prevent you from starting an independent Java
>> release.
>> >
>> > I've put some of my thoughts regarding source-tree organization down in
>> > the wiki. Please feel free to add your own.
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
>> >
>> > Whatever we decide on, we don't have to do it all at once in a big bang.
>> > We can incrementally move modules into a new structure.
>> >
>> > Justin
>> >
>> >
>> > On Fri, Jan 9, 2015 at 4:34 AM, Keith W <ke...@gmail.com> wrote:
>> >
>> >> Hi all,
>> >>
>> >> Looking through this thread, it is not clear that we came to a settled
>> >> position for release numbering, and when exactly we'd would move to
>> >> releasing components independently. On the java side we are getting
>> to a
>> >> position where a release soon would be sensible. How best do we go
>> >> forward?
>> >>
>> >> I'll be ready to put in some time helping plan/make the changes to the
>> >> release system happen, once we agree what that direction should be.
>> >>
>> >> Kind regards, Keith.
>> >>
>> >>
>> >>
>> >> On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
>> >> wrote:
>> >>
>> >> > In addition to [point] releases not actually occuring at the time the
>> >> > version suggests, for me another downside of using the Year.Month
>> >> > approach is that it doesnt as clearly convey a sense of impact for
>> the
>> >> > changes involved in the release, i.e is it a major or minor release,
>> >> > are there any compatibility considerations etc. It might for a bugfix
>> >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
>> >> > majorly different than 15.12 or not, given it might have nearly 2
>> >> > months of changes in it, or possibly just days? If it isnt,
>> >> > could/should it have been labeled 15.12.1 instead (at which point,
>> >> > back to that naming vs timing issue)? Obviously we dont convey that
>> >> > sort of information with the current versions, but it would be nice
>> to
>> >> > start.
>> >> >
>> >> > The major example of Year.Month naming that springs to mind for me is
>> >> > Ubuntu, which isnt really quite the same situations since their
>> >> > releases are mostly a distribution of other components, whicht are
>> all
>> >> > versioned independently and can often be updated to an extent between
>> >> > the containing Year.Month distribution releases. I can't immediately
>> >> > think of seeing any Apache projects using it as a convention, but I
>> >> > assume there are some.
>> >> >
>> >> > Robbie
>> >> >
>> >> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
>> >> wrote:
>> >> > > Agreed - we'd use target date.
>> >> > >
>> >> > > To Robbie's earlier comment on point releases, we (Java side) might
>> >> then
>> >> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where
>> the
>> >> next
>> >> > > scheduled release would be a 15.5 or whatever (ideally on the java
>> >> side I
>> >> > > think we'd like to move to more frequent releases, but that's a
>> >> separate
>> >> > > issue).
>> >> > >
>> >> > > -- Rob
>> >> > >
>> >> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
>> >> > >
>> >> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
>> >> > >>
>> >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com>
>> wrote:
>> >> > >>>
>> >> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
>> >> > >>>>
>> >> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at
>> >> this
>> >> > >>>>>
>> >> > >>>>>> point is meaningless and even perhaps confusing. They are both
>> >> well
>> >> > >>>>>> past
>> >> > >>>>>> that really, placing a high priority on stability and backward
>> >> > >>>>>> compatibility. The 1.0 label to me is more appropriate for
>> newer
>> >> > >>>>>> components like proton, dispatch-router and the new JMS
>> client.
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>> There's a certain appeal to having the version number be the
>> >> > year.month
>> >> > >>>>> that the product was branched especially if we have four or
>> five
>> >> > >>>>> closely related products. If some whizzy feature of the broker
>> >> > >>>>> is released in 15.4 then you know that it probably isn't
>> >> supported in
>> >> > >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2
>> >> and
>> >> > >>>>> dispatch is 1.1.
>> >> > >>>>>
>> >> > >>>>>
>> >> > >>>> Yes, I can see the value in being able to easily determine
>> ordering
>> >> > >>>> between release numbers of components on different schedules.
>> >> Also, it
>> >> > >>>> may
>> >> > >>>> help force a more public schedule, by setting the target date in
>> >> > order to
>> >> > >>>> determine the next release number.
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>> I like the idea, but I think it would be "unstable". During the
>> >> > release
>> >> > >>> process, we'd have to talk about 15.next or something like that
>> >> because
>> >> > >>> it's too hard to know exactly which month we will finish. "3.2"
>> >> would
>> >> > be
>> >> > >>> easier to talk about with precision.
>> >> > >>>
>> >> > >>
>> >> > >> I think you would use the target date, not the actual date. So
>> 15.1
>> >> > might
>> >> > >> actually not be ready until february, but you wouldn't change the
>> >> > release
>> >> > >> number. Otherwise I would agree with you it would be too fluid.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> ---------------------------------------------------------------------
>> >> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > >> For additional commands, e-mail: users-help@qpid.apache.org
>> >> > >>
>> >> > >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: users-help@qpid.apache.org
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Any ETA on a QPid 0.32 release
Posted by Rob Godfrey <ro...@gmail.com>.
I strongly agree with Keith that any change to the source tree should
happen (immediately) after (branching for) the next release. We can have
separate people managing the different components if we like, but I think
for this release we would be looking at a single release date and running
the existing release scripts. After this release we can work out exactly
how we want to release each component separately.
In terms of numbering, I'm relatively relaxed as to whether we change now
or at the next release - I don't think the two changes have to be
coincident.
As an aside, in terms of release numbering, somewhat coincidentally this
will be (if I have calculated this correctly) the 15th release of Qpid
since graduation (the first release was 0.5, then 0.6 and thereafter we
always incremented by 0.2), so calling this release 15.1 (as the first
release after an arbitrary rebasing of the version numbers) would be fine
by me :-)
-- Rob
On 23 January 2015 at 15:54, Keith W <ke...@gmail.com> wrote:
> Hi Justin
>
> I'm in agreement with the plan to reorganise the source tree in the way you
> describe (and expect that we would want a similar change for java) but am I
> concerned about the timing of such a big change. We should be
> reorganising trunk just *after* a release branch to give us plenty of time
> to work through the inevitable unexpected consequences properly.
>
> I am in favour of having one more qpid-wide release (and I would suggest we
> stick with our existing numbering scheme i.e. 0.32), then split the source
> tree and adopt the new numbering convention for the next -modular-
> releases.
>
> Thoughts?
>
> cheers, Keith.
>
>
>
>
> On 21 January 2015 at 12:35, Justin Ross <ju...@gmail.com> wrote:
>
> > Hi, Keith.
> >
> > Apart from picking an approach for version numbers, I don't think there
> is
> > anything that should prevent you from starting an independent Java
> release.
> >
> > I've put some of my thoughts regarding source-tree organization down in
> > the wiki. Please feel free to add your own.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
> >
> > Whatever we decide on, we don't have to do it all at once in a big bang.
> > We can incrementally move modules into a new structure.
> >
> > Justin
> >
> >
> > On Fri, Jan 9, 2015 at 4:34 AM, Keith W <ke...@gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> Looking through this thread, it is not clear that we came to a settled
> >> position for release numbering, and when exactly we'd would move to
> >> releasing components independently. On the java side we are getting
> to a
> >> position where a release soon would be sensible. How best do we go
> >> forward?
> >>
> >> I'll be ready to put in some time helping plan/make the changes to the
> >> release system happen, once we agree what that direction should be.
> >>
> >> Kind regards, Keith.
> >>
> >>
> >>
> >> On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
> >> wrote:
> >>
> >> > In addition to [point] releases not actually occuring at the time the
> >> > version suggests, for me another downside of using the Year.Month
> >> > approach is that it doesnt as clearly convey a sense of impact for the
> >> > changes involved in the release, i.e is it a major or minor release,
> >> > are there any compatibility considerations etc. It might for a bugfix
> >> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
> >> > majorly different than 15.12 or not, given it might have nearly 2
> >> > months of changes in it, or possibly just days? If it isnt,
> >> > could/should it have been labeled 15.12.1 instead (at which point,
> >> > back to that naming vs timing issue)? Obviously we dont convey that
> >> > sort of information with the current versions, but it would be nice to
> >> > start.
> >> >
> >> > The major example of Year.Month naming that springs to mind for me is
> >> > Ubuntu, which isnt really quite the same situations since their
> >> > releases are mostly a distribution of other components, whicht are all
> >> > versioned independently and can often be updated to an extent between
> >> > the containing Year.Month distribution releases. I can't immediately
> >> > think of seeing any Apache projects using it as a convention, but I
> >> > assume there are some.
> >> >
> >> > Robbie
> >> >
> >> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
> >> wrote:
> >> > > Agreed - we'd use target date.
> >> > >
> >> > > To Robbie's earlier comment on point releases, we (Java side) might
> >> then
> >> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where the
> >> next
> >> > > scheduled release would be a 15.5 or whatever (ideally on the java
> >> side I
> >> > > think we'd like to move to more frequent releases, but that's a
> >> separate
> >> > > issue).
> >> > >
> >> > > -- Rob
> >> > >
> >> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
> >> > >
> >> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
> >> > >>
> >> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com>
> wrote:
> >> > >>>
> >> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
> >> > >>>>
> >> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at
> >> this
> >> > >>>>>
> >> > >>>>>> point is meaningless and even perhaps confusing. They are both
> >> well
> >> > >>>>>> past
> >> > >>>>>> that really, placing a high priority on stability and backward
> >> > >>>>>> compatibility. The 1.0 label to me is more appropriate for
> newer
> >> > >>>>>> components like proton, dispatch-router and the new JMS client.
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>> There's a certain appeal to having the version number be the
> >> > year.month
> >> > >>>>> that the product was branched especially if we have four or five
> >> > >>>>> closely related products. If some whizzy feature of the broker
> >> > >>>>> is released in 15.4 then you know that it probably isn't
> >> supported in
> >> > >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2
> >> and
> >> > >>>>> dispatch is 1.1.
> >> > >>>>>
> >> > >>>>>
> >> > >>>> Yes, I can see the value in being able to easily determine
> ordering
> >> > >>>> between release numbers of components on different schedules.
> >> Also, it
> >> > >>>> may
> >> > >>>> help force a more public schedule, by setting the target date in
> >> > order to
> >> > >>>> determine the next release number.
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>> I like the idea, but I think it would be "unstable". During the
> >> > release
> >> > >>> process, we'd have to talk about 15.next or something like that
> >> because
> >> > >>> it's too hard to know exactly which month we will finish. "3.2"
> >> would
> >> > be
> >> > >>> easier to talk about with precision.
> >> > >>>
> >> > >>
> >> > >> I think you would use the target date, not the actual date. So 15.1
> >> > might
> >> > >> actually not be ready until february, but you wouldn't change the
> >> > release
> >> > >> number. Otherwise I would agree with you it would be too fluid.
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > >> For additional commands, e-mail: users-help@qpid.apache.org
> >> > >>
> >> > >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >> >
> >>
> >
> >
>
Re: Any ETA on a QPid 0.32 release
Posted by Keith W <ke...@gmail.com>.
Hi Justin
I'm in agreement with the plan to reorganise the source tree in the way you
describe (and expect that we would want a similar change for java) but am I
concerned about the timing of such a big change. We should be
reorganising trunk just *after* a release branch to give us plenty of time
to work through the inevitable unexpected consequences properly.
I am in favour of having one more qpid-wide release (and I would suggest we
stick with our existing numbering scheme i.e. 0.32), then split the source
tree and adopt the new numbering convention for the next -modular- releases.
Thoughts?
cheers, Keith.
On 21 January 2015 at 12:35, Justin Ross <ju...@gmail.com> wrote:
> Hi, Keith.
>
> Apart from picking an approach for version numbers, I don't think there is
> anything that should prevent you from starting an independent Java release.
>
> I've put some of my thoughts regarding source-tree organization down in
> the wiki. Please feel free to add your own.
>
>
> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
>
> Whatever we decide on, we don't have to do it all at once in a big bang.
> We can incrementally move modules into a new structure.
>
> Justin
>
>
> On Fri, Jan 9, 2015 at 4:34 AM, Keith W <ke...@gmail.com> wrote:
>
>> Hi all,
>>
>> Looking through this thread, it is not clear that we came to a settled
>> position for release numbering, and when exactly we'd would move to
>> releasing components independently. On the java side we are getting to a
>> position where a release soon would be sensible. How best do we go
>> forward?
>>
>> I'll be ready to put in some time helping plan/make the changes to the
>> release system happen, once we agree what that direction should be.
>>
>> Kind regards, Keith.
>>
>>
>>
>> On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>> > In addition to [point] releases not actually occuring at the time the
>> > version suggests, for me another downside of using the Year.Month
>> > approach is that it doesnt as clearly convey a sense of impact for the
>> > changes involved in the release, i.e is it a major or minor release,
>> > are there any compatibility considerations etc. It might for a bugfix
>> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
>> > majorly different than 15.12 or not, given it might have nearly 2
>> > months of changes in it, or possibly just days? If it isnt,
>> > could/should it have been labeled 15.12.1 instead (at which point,
>> > back to that naming vs timing issue)? Obviously we dont convey that
>> > sort of information with the current versions, but it would be nice to
>> > start.
>> >
>> > The major example of Year.Month naming that springs to mind for me is
>> > Ubuntu, which isnt really quite the same situations since their
>> > releases are mostly a distribution of other components, whicht are all
>> > versioned independently and can often be updated to an extent between
>> > the containing Year.Month distribution releases. I can't immediately
>> > think of seeing any Apache projects using it as a convention, but I
>> > assume there are some.
>> >
>> > Robbie
>> >
>> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
>> wrote:
>> > > Agreed - we'd use target date.
>> > >
>> > > To Robbie's earlier comment on point releases, we (Java side) might
>> then
>> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where the
>> next
>> > > scheduled release would be a 15.5 or whatever (ideally on the java
>> side I
>> > > think we'd like to move to more frequent releases, but that's a
>> separate
>> > > issue).
>> > >
>> > > -- Rob
>> > >
>> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
>> > >
>> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
>> > >>
>> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com> wrote:
>> > >>>
>> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
>> > >>>>
>> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at
>> this
>> > >>>>>
>> > >>>>>> point is meaningless and even perhaps confusing. They are both
>> well
>> > >>>>>> past
>> > >>>>>> that really, placing a high priority on stability and backward
>> > >>>>>> compatibility. The 1.0 label to me is more appropriate for newer
>> > >>>>>> components like proton, dispatch-router and the new JMS client.
>> > >>>>>>
>> > >>>>>>
>> > >>>>> There's a certain appeal to having the version number be the
>> > year.month
>> > >>>>> that the product was branched especially if we have four or five
>> > >>>>> closely related products. If some whizzy feature of the broker
>> > >>>>> is released in 15.4 then you know that it probably isn't
>> supported in
>> > >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2
>> and
>> > >>>>> dispatch is 1.1.
>> > >>>>>
>> > >>>>>
>> > >>>> Yes, I can see the value in being able to easily determine ordering
>> > >>>> between release numbers of components on different schedules.
>> Also, it
>> > >>>> may
>> > >>>> help force a more public schedule, by setting the target date in
>> > order to
>> > >>>> determine the next release number.
>> > >>>>
>> > >>>
>> > >>>
>> > >>> I like the idea, but I think it would be "unstable". During the
>> > release
>> > >>> process, we'd have to talk about 15.next or something like that
>> because
>> > >>> it's too hard to know exactly which month we will finish. "3.2"
>> would
>> > be
>> > >>> easier to talk about with precision.
>> > >>>
>> > >>
>> > >> I think you would use the target date, not the actual date. So 15.1
>> > might
>> > >> actually not be ready until february, but you wouldn't change the
>> > release
>> > >> number. Otherwise I would agree with you it would be too fluid.
>> > >>
>> > >>
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > >> For additional commands, e-mail: users-help@qpid.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: users-help@qpid.apache.org
>> >
>> >
>>
>
>
Re: Any ETA on a QPid 0.32 release
Posted by Justin Ross <ju...@gmail.com>.
Hi, Keith.
Apart from picking an approach for version numbers, I don't think there is
anything that should prevent you from starting an independent Java release.
I've put some of my thoughts regarding source-tree organization down in the
wiki. Please feel free to add your own.
https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
Whatever we decide on, we don't have to do it all at once in a big bang.
We can incrementally move modules into a new structure.
Justin
On Fri, Jan 9, 2015 at 4:34 AM, Keith W <ke...@gmail.com> wrote:
> Hi all,
>
> Looking through this thread, it is not clear that we came to a settled
> position for release numbering, and when exactly we'd would move to
> releasing components independently. On the java side we are getting to a
> position where a release soon would be sensible. How best do we go
> forward?
>
> I'll be ready to put in some time helping plan/make the changes to the
> release system happen, once we agree what that direction should be.
>
> Kind regards, Keith.
>
>
>
> On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > In addition to [point] releases not actually occuring at the time the
> > version suggests, for me another downside of using the Year.Month
> > approach is that it doesnt as clearly convey a sense of impact for the
> > changes involved in the release, i.e is it a major or minor release,
> > are there any compatibility considerations etc. It might for a bugfix
> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
> > majorly different than 15.12 or not, given it might have nearly 2
> > months of changes in it, or possibly just days? If it isnt,
> > could/should it have been labeled 15.12.1 instead (at which point,
> > back to that naming vs timing issue)? Obviously we dont convey that
> > sort of information with the current versions, but it would be nice to
> > start.
> >
> > The major example of Year.Month naming that springs to mind for me is
> > Ubuntu, which isnt really quite the same situations since their
> > releases are mostly a distribution of other components, whicht are all
> > versioned independently and can often be updated to an extent between
> > the containing Year.Month distribution releases. I can't immediately
> > think of seeing any Apache projects using it as a convention, but I
> > assume there are some.
> >
> > Robbie
> >
> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
> wrote:
> > > Agreed - we'd use target date.
> > >
> > > To Robbie's earlier comment on point releases, we (Java side) might
> then
> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where the
> next
> > > scheduled release would be a 15.5 or whatever (ideally on the java
> side I
> > > think we'd like to move to more frequent releases, but that's a
> separate
> > > issue).
> > >
> > > -- Rob
> > >
> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
> > >
> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
> > >>
> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com> wrote:
> > >>>
> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
> > >>>>
> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at this
> > >>>>>
> > >>>>>> point is meaningless and even perhaps confusing. They are both
> well
> > >>>>>> past
> > >>>>>> that really, placing a high priority on stability and backward
> > >>>>>> compatibility. The 1.0 label to me is more appropriate for newer
> > >>>>>> components like proton, dispatch-router and the new JMS client.
> > >>>>>>
> > >>>>>>
> > >>>>> There's a certain appeal to having the version number be the
> > year.month
> > >>>>> that the product was branched especially if we have four or five
> > >>>>> closely related products. If some whizzy feature of the broker
> > >>>>> is released in 15.4 then you know that it probably isn't supported
> in
> > >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2 and
> > >>>>> dispatch is 1.1.
> > >>>>>
> > >>>>>
> > >>>> Yes, I can see the value in being able to easily determine ordering
> > >>>> between release numbers of components on different schedules. Also,
> it
> > >>>> may
> > >>>> help force a more public schedule, by setting the target date in
> > order to
> > >>>> determine the next release number.
> > >>>>
> > >>>
> > >>>
> > >>> I like the idea, but I think it would be "unstable". During the
> > release
> > >>> process, we'd have to talk about 15.next or something like that
> because
> > >>> it's too hard to know exactly which month we will finish. "3.2"
> would
> > be
> > >>> easier to talk about with precision.
> > >>>
> > >>
> > >> I think you would use the target date, not the actual date. So 15.1
> > might
> > >> actually not be ready until february, but you wouldn't change the
> > release
> > >> number. Otherwise I would agree with you it would be too fluid.
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: users-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: Any ETA on a QPid 0.32 release
Posted by Justin Ross <ju...@gmail.com>.
I apologize for the delay. I've put dates against the releases I'm
planning at the wiki pages below:
- https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02
- https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02
The cpp release will depend on Qpid Proton 0.9, and I'm bundling the tools
artifact (exclusive of the Java QMF stuff) with it.
Justin
On Thu, Jan 15, 2015 at 5:12 AM, Rob Godfrey <ro...@gmail.com>
wrote:
> Justin,
>
> do you have proposed dates for 0.32 alpha/beta/release? It would be good
> to get another release out soon.
>
> -- Rob
Re: Any ETA on a QPid 0.32 release
Posted by Rob Godfrey <ro...@gmail.com>.
Justin,
do you have proposed dates for 0.32 alpha/beta/release? It would be good
to get another release out soon.
-- Rob
On 9 January 2015 at 10:34, Keith W <ke...@gmail.com> wrote:
> Hi all,
>
> Looking through this thread, it is not clear that we came to a settled
> position for release numbering, and when exactly we'd would move to
> releasing components independently. On the java side we are getting to a
> position where a release soon would be sensible. How best do we go
> forward?
>
> I'll be ready to put in some time helping plan/make the changes to the
> release system happen, once we agree what that direction should be.
>
> Kind regards, Keith.
>
>
>
> On 3 December 2014 at 15:15, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > In addition to [point] releases not actually occuring at the time the
> > version suggests, for me another downside of using the Year.Month
> > approach is that it doesnt as clearly convey a sense of impact for the
> > changes involved in the release, i.e is it a major or minor release,
> > are there any compatibility considerations etc. It might for a bugfix
> > release, e.g 15.1.1 vs 15.1, however should 16.1 be expected to be
> > majorly different than 15.12 or not, given it might have nearly 2
> > months of changes in it, or possibly just days? If it isnt,
> > could/should it have been labeled 15.12.1 instead (at which point,
> > back to that naming vs timing issue)? Obviously we dont convey that
> > sort of information with the current versions, but it would be nice to
> > start.
> >
> > The major example of Year.Month naming that springs to mind for me is
> > Ubuntu, which isnt really quite the same situations since their
> > releases are mostly a distribution of other components, whicht are all
> > versioned independently and can often be updated to an extent between
> > the containing Year.Month distribution releases. I can't immediately
> > think of seeing any Apache projects using it as a convention, but I
> > assume there are some.
> >
> > Robbie
> >
> > On 3 December 2014 at 11:50, Rob Godfrey <ro...@gmail.com>
> wrote:
> > > Agreed - we'd use target date.
> > >
> > > To Robbie's earlier comment on point releases, we (Java side) might
> then
> > > subsequently release a 15.1.1 as a bugfix release of 15.1, where the
> next
> > > scheduled release would be a 15.5 or whatever (ideally on the java
> side I
> > > think we'd like to move to more frequent releases, but that's a
> separate
> > > issue).
> > >
> > > -- Rob
> > >
> > > On 3 December 2014 at 12:21, Gordon Sim <gs...@redhat.com> wrote:
> > >
> > >> On 12/03/2014 11:02 AM, Justin Ross wrote:
> > >>
> > >>> On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim <gs...@redhat.com> wrote:
> > >>>
> > >>> On 12/02/2014 09:59 PM, Chuck Rolke wrote:
> > >>>>
> > >>>> I feel like for qpidd and qpid::messaging at least, a '1.0' at this
> > >>>>>
> > >>>>>> point is meaningless and even perhaps confusing. They are both
> well
> > >>>>>> past
> > >>>>>> that really, placing a high priority on stability and backward
> > >>>>>> compatibility. The 1.0 label to me is more appropriate for newer
> > >>>>>> components like proton, dispatch-router and the new JMS client.
> > >>>>>>
> > >>>>>>
> > >>>>> There's a certain appeal to having the version number be the
> > year.month
> > >>>>> that the product was branched especially if we have four or five
> > >>>>> closely related products. If some whizzy feature of the broker
> > >>>>> is released in 15.4 then you know that it probably isn't supported
> in
> > >>>>> dispatch 15.2. There's no way to know that if the broker is 3.2 and
> > >>>>> dispatch is 1.1.
> > >>>>>
> > >>>>>
> > >>>> Yes, I can see the value in being able to easily determine ordering
> > >>>> between release numbers of components on different schedules. Also,
> it
> > >>>> may
> > >>>> help force a more public schedule, by setting the target date in
> > order to
> > >>>> determine the next release number.
> > >>>>
> > >>>
> > >>>
> > >>> I like the idea, but I think it would be "unstable". During the
> > release
> > >>> process, we'd have to talk about 15.next or something like that
> because
> > >>> it's too hard to know exactly which month we will finish. "3.2"
> would
> > be
> > >>> easier to talk about with precision.
> > >>>
> > >>
> > >> I think you would use the target date, not the actual date. So 15.1
> > might
> > >> actually not be ready until february, but you wouldn't change the
> > release
> > >> number. Otherwise I would agree with you it would be too fluid.
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: users-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>