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 justin.r...@gmail.com wrote:
Based on what we've discussed so far, here's
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
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
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
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.
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
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
On 2 December 2014 at 19:31, Rob Godfrey rob.j.godf...@gmail.com wrote:
On 2 December 2014 at 19:25, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
On 2 December 2014 at 16:14, Rob Godfrey rob.j.godf...@gmail.com wrote:
Can we also move from version 0.32 to something more reflective of the
On 2 December 2014 at 21:59, Chuck Rolke cro...@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
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
On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim g...@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
On 12/03/2014 11:02 AM, Justin Ross wrote:
On Wed, Dec 3, 2014 at 5:00 AM, Gordon Sim g...@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
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
(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 robbie.gemm...@gmail.com
wrote:
The releases have usually been every 4 months or so, and the branch
for the last
On Wed, Dec 3, 2014 at 6:50 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:
Agreed - we'd use target date.
Okay, that sounds good to me.
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
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
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 2 December 2014 at 19:25, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
On 2 December 2014 at 16:14, Rob Godfrey rob.j.godf...@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
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
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,
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
22 matches
Mail list logo
