Any ETA on a QPid 0.32 release

[Timothy Bish <ta...@gmail.com>]

We've been working on improving the AMQP 1.0 support in ActiveMQ and 
I've found that the trunk code for QPid JMS client contains some fixes 
that would be nice to have in for testing the fixes that are in the 
pipeline for the broker.  Was wondering if there is any idea on when the 
0.32 release process might start rolling?

-- 
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/


---------------------------------------------------------------------
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

[Justin Ross <ju...@gmail.com>]

(My apologies if this comes through twice.  I sent an earlier copy with my
apache address, and it didn't apparently make it.)

On Tue, Dec 2, 2014 at 10:48 AM, Robbie Gemmell <ro...@gmail.com>
 wrote:

> The releases have usually been every 4 months or so, and the branch
> for the last release was made about 4 months ago, so I guess the plan
> should be to branch sometime soon. Typically releases that begin in
> Nov/Dec dont emerge until some point in January. Any plans on dates
> Justin?
>

I'd like to start a coordinated release of proton and qpid/cpp in January.
There's a new feature of the C++ messaging API, local transactions for 1.0,
that depends on fixes that should appear in proton 0.9.


> Of course, we have discussed the project being more modular, updated
> the release artifacts along those lines to be more component based,
> and voted on them seperately last time round, so potentially we could
> look to take a further step and release different bits at different
> times now. Thoughts anyone?


I've been assuming that the qpid/java releases, at a minimum, would be
independent after 0.30.  And I don't think there's anything that should
prevent our doing that for the other components as well.

Re: Any ETA on a QPid 0.32 release

[Robbie Gemmell <ro...@gmail.com>]

On 2 December 2014 at 21:59, Chuck Rolke <cr...@redhat.com> 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.

I'm not sure that really holds if things are being released
independently. I think it can be clearer in some cases, but is often
going to be more confusing as well. Unless their release dates match
and they co-developed a brand new feature, one component quite likely
supported something to do with the feature before the other, in which
case the versions wont match anyway. Backporting might later mean
support for something gets added to prior <Year.Month.Patch> releases
for one component but not the other, leading to further mismatch (and
other things such as odd looking releases that dont match the year or
months in their version).

>
> My preferences in order are:
>
> 1. All products with 'year'.'month'.
> 2. All products switch to 3.1 on next release and increment independently.
>
> ---------------------------------------------------------------------
> 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

[Justin Ross <ju...@gmail.com>]

On Wed, Dec 3, 2014 at 6:50 AM, Rob Godfrey <ro...@gmail.com> wrote:

> Agreed - we'd use target date.
>

Okay, that sounds good to me.

Re: Use of qpid rather than RabbitMQ in openstack

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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
> >
> >
>

Re: Any ETA on a QPid 0.32 release

[Keith W <ke...@gmail.com>]

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

[Robbie Gemmell <ro...@gmail.com>]

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

[Rob Godfrey <ro...@gmail.com>]

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
>
>

Re: Any ETA on a QPid 0.32 release

[Gordon Sim <gs...@redhat.com>]

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

Re: Any ETA on a QPid 0.32 release

[Justin Ross <ju...@gmail.com>]

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.

Re: Any ETA on a QPid 0.32 release

[Gordon Sim <gs...@redhat.com>]

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.

> My preferences in order are:
>
> 1. All products with 'year'.'month'.
> 2. All products switch to 3.1 on next release and increment independently.


---------------------------------------------------------------------
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

[Chuck Rolke <cr...@redhat.com>]

> 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.

My preferences in order are:

1. All products with 'year'.'month'.
2. All products switch to 3.1 on next release and increment independently.

---------------------------------------------------------------------
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

[Gordon Sim <gs...@redhat.com>]

On 12/02/2014 07:09 PM, Fraser Adams wrote:
> It has always felt slightly odd to me that Qpid has never had a version
> 1.0. I guess that in the back of my mind (and back in the day) I perhaps
> assumed that it would hit V1.0 with AMQP 1.0 support, but that didn't
> occur.
>
> I guess one thing that might be worth considering is to hold fire on a
> change until a couple of significant AMQP 1.0 changes occur - I guess
> that the two things that spring to mind would be
> 1) qpidd making AMQP 0.10 support optional

At present 0-10 support in qpidd can be disabled if desired.

> 2) availability/maturity of the new Proton based AMQP 1.0 JMS client

Since that is assumed at this point to be separately released anyway, 
I'm not sure it makes sense for it to impact the version number of 
other, older and more mature components on a different schedule, unless 
you are thinking it would be only at that point their 1.0 support could 
be sufficiently tested.

> TBH I don't really know the timeline for these and it might be a bit
> moot if they are a long way off, but I've always felt that there was a
> fair bit of confusion around the status of AMQP 1.0 JMS support so being
> able to deprecate the current interim client feels a fairly significant
> step on the maturity of AMQP 1.0 support.
>
> Or is there a Qpid birthday coming up? The project running X years is
> probably another reasonable point to trigger a 1.0 release.
>
>
> TBH I don't think the current numbering system is massively broken, at
> the very least it's something that we and most users have got used to.  I
> think my personal preference is to pick a sensible point to move to 1.0,
> but I'm not going to die in a ditch about any other suggestions.

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.

---------------------------------------------------------------------
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

[Fraser Adams <fr...@blueyonder.co.uk>]

It has always felt slightly odd to me that Qpid has never had a version 
1.0. I guess that in the back of my mind (and back in the day) I perhaps 
assumed that it would hit V1.0 with AMQP 1.0 support, but that didn't occur.

I guess one thing that might be worth considering is to hold fire on a 
change until a couple of significant AMQP 1.0 changes occur - I guess 
that the two things that spring to mind would be
1) qpidd making AMQP 0.10 support optional
2) availability/maturity of the new Proton based AMQP 1.0 JMS client

TBH I don't really know the timeline for these and it might be a bit 
moot if they are a long way off, but I've always felt that there was a 
fair bit of confusion around the status of AMQP 1.0 JMS support so being 
able to deprecate the current interim client feels a fairly significant 
step on the maturity of AMQP 1.0 support.

Or is there a Qpid birthday coming up? The project running X years is 
probably another reasonable point to trigger a 1.0 release.


TBH I don't think the current numbering system is massively broken, at 
the very least it's something that we and most users have got used to. I 
think my personal preference is to pick a sensible point to move to 1.0, 
but I'm not going to die in a ditch about any other suggestions.

Frase

On 02/12/14 18:25, Robbie Gemmell wrote:
> On 2 December 2014 at 16:14, Rob Godfrey <ro...@gmail.com> wrote:
>> Can we also move from version 0.32 to something more reflective of the
>> maturity of the product?
>>
> Seems reasonable.
>
>> I feel like we've held off so long that going to release "1.0" now would
>> seem strange, and also imply something significant had happened in that
>> release which it hasn't.
> Agreed.
>
>> Personally I'd go for something like 15.1  (not
>> necessarily to indicate that we'd go for year.month in the future... but
>> just as a arbitrary starting point).
> <Arbitrary>.0 or <Year>.0 would suit me too.
>
> I'd quite like at least some components to support point releases
> eventually instead of just timed released, so in some ways arbitrary
> numbers seem preferable such that we dont end up doing too many odd
> looking point releases or even skipping numbers for slow moving
> components hehe.
>
>> I'd also be in favour of separating
>> out the components a bit - from the Java side we'd probably then look to
>> branch later but spend less time on a branch before release.
>>
> Do you mean branch at different points but still potentially release
> at similar times, or release at independent times? The latter was what
> I meant.
>
> A question for me is, if we did support releasing at different times
> then things will likely end up with different version numbers anyway,
> so do they need to start at the same place if we change from our
> historic naming convention? Would it be clearer or more confusing if
> they differed initially, or started the same and then diverged?
>
> One thing that I have mentioned before is that if we were to look at
> branching at different times, I think the repo needs better organised
> along the structure of likely branching, otherwise it just becomes a
> pain and the branches end up with potentially confusing junk on them
> for other bits. <Insert timely mention of Git, then run :P>.
>
> Robbie
>
>
>> -- Rob
>>
>> On 2 December 2014 at 16:48, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> The releases have usually been every 4 months or so, and the branch
>>> for the last release was made about 4 months ago, so I guess the plan
>>> should be to branch sometime soon. Typically releases that begin in
>>> Nov/Dec dont emerge until some point in January. Any plans on dates
>>> Justin?
>>>
>>> Of course, we have discussed the project being more modular, updated
>>> the release artifacts along those lines to be more component based,
>>> and voted on them seperately last time round, so potentially we could
>>> look to take a further step and release different bits at different
>>> times now. Thoughts anyone?
>>>
>>> Robbie
>>>
>>> On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
>>>> We've been working on improving the AMQP 1.0 support in ActiveMQ and I've
>>>> found that the trunk code for QPid JMS client contains some fixes that
>>> would
>>>> be nice to have in for testing the fixes that are in the pipeline for the
>>>> broker.  Was wondering if there is any idea on when the 0.32 release
>>> process
>>>> might start rolling?
>>>>
>>>> --
>>>> Tim Bish
>>>> Sr Software Engineer | RedHat Inc.
>>>> tim.bish@redhat.com | www.redhat.com
>>>> skype: tabish121 | twitter: @tabish121
>>>> blog: http://timbish.blogspot.com/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
> ---------------------------------------------------------------------
> 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

[Robbie Gemmell <ro...@gmail.com>]

On 2 December 2014 at 19:31, Rob Godfrey <ro...@gmail.com> wrote:
> On 2 December 2014 at 19:25, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 2 December 2014 at 16:14, Rob Godfrey <ro...@gmail.com> wrote:
>> > Can we also move from version 0.32 to something more reflective of the
>> > maturity of the product?
>> >
>>
>> Seems reasonable.
>>
>> > I feel like we've held off so long that going to release "1.0" now would
>> > seem strange, and also imply something significant had happened in that
>> > release which it hasn't.
>>
>> Agreed.
>>
>> > Personally I'd go for something like 15.1  (not
>> > necessarily to indicate that we'd go for year.month in the future... but
>> > just as a arbitrary starting point).
>>
>> <Arbitrary>.0 or <Year>.0 would suit me too.
>>
>> I'd quite like at least some components to support point releases
>> eventually instead of just timed released, so in some ways arbitrary
>> numbers seem preferable such that we dont end up doing too many odd
>> looking point releases or even skipping numbers for slow moving
>> components hehe.
>>
>>
> Agreed - this is something I want to support too... from where I sit that
> will be easier when each component has more control over their release
> timelines.
>
>
>> > I'd also be in favour of separating
>> > out the components a bit - from the Java side we'd probably then look to
>> > branch later but spend less time on a branch before release.
>> >
>>
>> Do you mean branch at different points but still potentially release
>> at similar times, or release at independent times? The latter was what
>> I meant.
>>
>
> The latter should be possible, the former might be socially convenient (and
> also mean less overall need for interop testing between components, which
> is not something we seem to have well automated).  One of my problems with
> the current release process is that we always tend to take a *long* time in
> the branched state, and the branching seems to occur at a somewhat
> arbitrary point.  I'd rather be saying "OK, we as a collection group of
> developers for <X component> now believe we are ready to go to beta"...
>
>>
>> A question for me is, if we did support releasing at different times
>> then things will likely end up with different version numbers anyway,
>> so do they need to start at the same place if we change from our
>> historic naming convention? Would it be clearer or more confusing if
>> they differed initially, or started the same and then diverged?
>>
>
> Right now it seems to me that the only coupling between the Java and C++
> releases is temporal, not functional.  If we use a non date based version
> numbering system, the coupling of the Java and C++ releases seems somewhat
> odd - we don't currently (nor have we really ever) planned across the whole
> project to coordinate functional releases.  Similarly there's never really
> any "good" time to move up major version while the releases are coupled
> (since we never do "major" stuff at the same time) which is why I think
> we've never gone to v1.0 previously.
>
>
>>
>> One thing that I have mentioned before is that if we were to look at
>> branching at different times, I think the repo needs better organised
>> along the structure of likely branching, otherwise it just becomes a
>> pain and the branches end up with potentially confusing junk on them
>> for other bits. <Insert timely mention of Git, then run :P>.
>>
>
> Agreed on better structure - I think git is somewhat orthogonal... We need
> to get the structure right whatever.

Almost completely orthogonal really, I only mentioned it because of
the obvious need to reorganise bits if they were to be split between
multiple git repos, but we would probably want to change the structure
before such a switch anyway.

>
> -- Rob
>
>
>> Robbie
>>
>>
>> > -- Rob
>> >
>> > On 2 December 2014 at 16:48, Robbie Gemmell <ro...@gmail.com>
>> > wrote:
>> >
>> >> The releases have usually been every 4 months or so, and the branch
>> >> for the last release was made about 4 months ago, so I guess the plan
>> >> should be to branch sometime soon. Typically releases that begin in
>> >> Nov/Dec dont emerge until some point in January. Any plans on dates
>> >> Justin?
>> >>
>> >> Of course, we have discussed the project being more modular, updated
>> >> the release artifacts along those lines to be more component based,
>> >> and voted on them seperately last time round, so potentially we could
>> >> look to take a further step and release different bits at different
>> >> times now. Thoughts anyone?
>> >>
>> >> Robbie
>> >>
>> >> On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
>> >> > We've been working on improving the AMQP 1.0 support in ActiveMQ and
>> I've
>> >> > found that the trunk code for QPid JMS client contains some fixes that
>> >> would
>> >> > be nice to have in for testing the fixes that are in the pipeline for
>> the
>> >> > broker.  Was wondering if there is any idea on when the 0.32 release
>> >> process
>> >> > might start rolling?
>> >> >
>> >> > --
>> >> > Tim Bish
>> >> > Sr Software Engineer | RedHat Inc.
>> >> > tim.bish@redhat.com | www.redhat.com
>> >> > skype: tabish121 | twitter: @tabish121
>> >> > blog: http://timbish.blogspot.com/
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > 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
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> 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

[Rob Godfrey <ro...@gmail.com>]

On 2 December 2014 at 19:25, Robbie Gemmell <ro...@gmail.com>
wrote:

> On 2 December 2014 at 16:14, Rob Godfrey <ro...@gmail.com> wrote:
> > Can we also move from version 0.32 to something more reflective of the
> > maturity of the product?
> >
>
> Seems reasonable.
>
> > I feel like we've held off so long that going to release "1.0" now would
> > seem strange, and also imply something significant had happened in that
> > release which it hasn't.
>
> Agreed.
>
> > Personally I'd go for something like 15.1  (not
> > necessarily to indicate that we'd go for year.month in the future... but
> > just as a arbitrary starting point).
>
> <Arbitrary>.0 or <Year>.0 would suit me too.
>
> I'd quite like at least some components to support point releases
> eventually instead of just timed released, so in some ways arbitrary
> numbers seem preferable such that we dont end up doing too many odd
> looking point releases or even skipping numbers for slow moving
> components hehe.
>
>
Agreed - this is something I want to support too... from where I sit that
will be easier when each component has more control over their release
timelines.


> > I'd also be in favour of separating
> > out the components a bit - from the Java side we'd probably then look to
> > branch later but spend less time on a branch before release.
> >
>
> Do you mean branch at different points but still potentially release
> at similar times, or release at independent times? The latter was what
> I meant.
>

The latter should be possible, the former might be socially convenient (and
also mean less overall need for interop testing between components, which
is not something we seem to have well automated).  One of my problems with
the current release process is that we always tend to take a *long* time in
the branched state, and the branching seems to occur at a somewhat
arbitrary point.  I'd rather be saying "OK, we as a collection group of
developers for <X component> now believe we are ready to go to beta"...

>
> A question for me is, if we did support releasing at different times
> then things will likely end up with different version numbers anyway,
> so do they need to start at the same place if we change from our
> historic naming convention? Would it be clearer or more confusing if
> they differed initially, or started the same and then diverged?
>

Right now it seems to me that the only coupling between the Java and C++
releases is temporal, not functional.  If we use a non date based version
numbering system, the coupling of the Java and C++ releases seems somewhat
odd - we don't currently (nor have we really ever) planned across the whole
project to coordinate functional releases.  Similarly there's never really
any "good" time to move up major version while the releases are coupled
(since we never do "major" stuff at the same time) which is why I think
we've never gone to v1.0 previously.


>
> One thing that I have mentioned before is that if we were to look at
> branching at different times, I think the repo needs better organised
> along the structure of likely branching, otherwise it just becomes a
> pain and the branches end up with potentially confusing junk on them
> for other bits. <Insert timely mention of Git, then run :P>.
>

Agreed on better structure - I think git is somewhat orthogonal... We need
to get the structure right whatever.

-- Rob


> Robbie
>
>
> > -- Rob
> >
> > On 2 December 2014 at 16:48, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> >> The releases have usually been every 4 months or so, and the branch
> >> for the last release was made about 4 months ago, so I guess the plan
> >> should be to branch sometime soon. Typically releases that begin in
> >> Nov/Dec dont emerge until some point in January. Any plans on dates
> >> Justin?
> >>
> >> Of course, we have discussed the project being more modular, updated
> >> the release artifacts along those lines to be more component based,
> >> and voted on them seperately last time round, so potentially we could
> >> look to take a further step and release different bits at different
> >> times now. Thoughts anyone?
> >>
> >> Robbie
> >>
> >> On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
> >> > We've been working on improving the AMQP 1.0 support in ActiveMQ and
> I've
> >> > found that the trunk code for QPid JMS client contains some fixes that
> >> would
> >> > be nice to have in for testing the fixes that are in the pipeline for
> the
> >> > broker.  Was wondering if there is any idea on when the 0.32 release
> >> process
> >> > might start rolling?
> >> >
> >> > --
> >> > Tim Bish
> >> > Sr Software Engineer | RedHat Inc.
> >> > tim.bish@redhat.com | www.redhat.com
> >> > skype: tabish121 | twitter: @tabish121
> >> > blog: http://timbish.blogspot.com/
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >>
> >>
>
> ---------------------------------------------------------------------
> 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

[Robbie Gemmell <ro...@gmail.com>]

On 2 December 2014 at 16:14, Rob Godfrey <ro...@gmail.com> wrote:
> Can we also move from version 0.32 to something more reflective of the
> maturity of the product?
>

Seems reasonable.

> I feel like we've held off so long that going to release "1.0" now would
> seem strange, and also imply something significant had happened in that
> release which it hasn't.

Agreed.

> Personally I'd go for something like 15.1  (not
> necessarily to indicate that we'd go for year.month in the future... but
> just as a arbitrary starting point).

<Arbitrary>.0 or <Year>.0 would suit me too.

I'd quite like at least some components to support point releases
eventually instead of just timed released, so in some ways arbitrary
numbers seem preferable such that we dont end up doing too many odd
looking point releases or even skipping numbers for slow moving
components hehe.

> I'd also be in favour of separating
> out the components a bit - from the Java side we'd probably then look to
> branch later but spend less time on a branch before release.
>

Do you mean branch at different points but still potentially release
at similar times, or release at independent times? The latter was what
I meant.

A question for me is, if we did support releasing at different times
then things will likely end up with different version numbers anyway,
so do they need to start at the same place if we change from our
historic naming convention? Would it be clearer or more confusing if
they differed initially, or started the same and then diverged?

One thing that I have mentioned before is that if we were to look at
branching at different times, I think the repo needs better organised
along the structure of likely branching, otherwise it just becomes a
pain and the branches end up with potentially confusing junk on them
for other bits. <Insert timely mention of Git, then run :P>.

Robbie


> -- Rob
>
> On 2 December 2014 at 16:48, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> The releases have usually been every 4 months or so, and the branch
>> for the last release was made about 4 months ago, so I guess the plan
>> should be to branch sometime soon. Typically releases that begin in
>> Nov/Dec dont emerge until some point in January. Any plans on dates
>> Justin?
>>
>> Of course, we have discussed the project being more modular, updated
>> the release artifacts along those lines to be more component based,
>> and voted on them seperately last time round, so potentially we could
>> look to take a further step and release different bits at different
>> times now. Thoughts anyone?
>>
>> Robbie
>>
>> On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
>> > We've been working on improving the AMQP 1.0 support in ActiveMQ and I've
>> > found that the trunk code for QPid JMS client contains some fixes that
>> would
>> > be nice to have in for testing the fixes that are in the pipeline for the
>> > broker.  Was wondering if there is any idea on when the 0.32 release
>> process
>> > might start rolling?
>> >
>> > --
>> > Tim Bish
>> > Sr Software Engineer | RedHat Inc.
>> > tim.bish@redhat.com | www.redhat.com
>> > skype: tabish121 | twitter: @tabish121
>> > blog: http://timbish.blogspot.com/
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>

---------------------------------------------------------------------
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

[Gordon Sim <gs...@redhat.com>]

On 12/02/2014 04:14 PM, Rob Godfrey wrote:
> Can we also move from version 0.32 to something more reflective of the
> maturity of the product?

3.2?

[...]
> I'd also be in favour of separating
> out the components a bit - from the Java side we'd probably then look to
> branch later but spend less time on a branch before release.

I have no issue with releasing components on different schedules.

However I do think it is very important that every component has an 
established release schedule published well in advance.

The 'main' qpid release has at least given a fairly predictable 
periodicity to releases, though we could certainly do better at 
publishing roadmaps in advance.

The proton 0.9 roadmap is very welcome. However I think previously, 
proton and dispatch releases are hard to predict or understand for the 
general public and we want to make that sort of uncertainty less common.

Obviously dates can slip a little here or there and that's normal. The 
key is just to give some window into the future plans for every 
component to all who might be interested.

---------------------------------------------------------------------
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

[Rob Godfrey <ro...@gmail.com>]

Can we also move from version 0.32 to something more reflective of the
maturity of the product?

I feel like we've held off so long that going to release "1.0" now would
seem strange, and also imply something significant had happened in that
release which it hasn't.  Personally I'd go for something like 15.1  (not
necessarily to indicate that we'd go for year.month in the future... but
just as a arbitrary starting point).  I'd also be in favour of separating
out the components a bit - from the Java side we'd probably then look to
branch later but spend less time on a branch before release.

-- Rob

On 2 December 2014 at 16:48, Robbie Gemmell <ro...@gmail.com>
wrote:

> The releases have usually been every 4 months or so, and the branch
> for the last release was made about 4 months ago, so I guess the plan
> should be to branch sometime soon. Typically releases that begin in
> Nov/Dec dont emerge until some point in January. Any plans on dates
> Justin?
>
> Of course, we have discussed the project being more modular, updated
> the release artifacts along those lines to be more component based,
> and voted on them seperately last time round, so potentially we could
> look to take a further step and release different bits at different
> times now. Thoughts anyone?
>
> Robbie
>
> On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
> > We've been working on improving the AMQP 1.0 support in ActiveMQ and I've
> > found that the trunk code for QPid JMS client contains some fixes that
> would
> > be nice to have in for testing the fixes that are in the pipeline for the
> > broker.  Was wondering if there is any idea on when the 0.32 release
> process
> > might start rolling?
> >
> > --
> > Tim Bish
> > Sr Software Engineer | RedHat Inc.
> > tim.bish@redhat.com | www.redhat.com
> > skype: tabish121 | twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
> > ---------------------------------------------------------------------
> > 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

[Robbie Gemmell <ro...@gmail.com>]

The releases have usually been every 4 months or so, and the branch
for the last release was made about 4 months ago, so I guess the plan
should be to branch sometime soon. Typically releases that begin in
Nov/Dec dont emerge until some point in January. Any plans on dates
Justin?

Of course, we have discussed the project being more modular, updated
the release artifacts along those lines to be more component based,
and voted on them seperately last time round, so potentially we could
look to take a further step and release different bits at different
times now. Thoughts anyone?

Robbie

On 1 December 2014 at 22:11, Timothy Bish <ta...@gmail.com> wrote:
> We've been working on improving the AMQP 1.0 support in ActiveMQ and I've
> found that the trunk code for QPid JMS client contains some fixes that would
> be nice to have in for testing the fixes that are in the pipeline for the
> broker.  Was wondering if there is any idea on when the 0.32 release process
> might start rolling?
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
> ---------------------------------------------------------------------
> 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