You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2017/01/16 18:38:04 UTC
[VOTE] Release Qpid JMS client 0.20.0
Hi folks,
I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.
The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097
Regards,
Robbie
P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:
<repositories>
<repository>
<id>staging</id>
<url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
</repository>
</repositories>
The dependency for the client itself would then be:
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-jms-client</artifactId>
<version>0.20.0</version>
</dependency>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [VOTE] Release Qpid JMS client 0.20.0
Posted by Timothy Bish <ta...@gmail.com>.
+1
* Validated the signatures and sums
* Reviewed the License and Notice files
* Reviewed the documentation file
* Built from source and ran the tests
* Used the staged artifacts in the ActiveMQ AMQP test suite
* Ran the provided examples against an ActiveMQ broker
On 01/16/2017 01:38 PM, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a spin for a 0.20.0 Qpid JMS client release,
> please test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1097
>
> Regards,
> Robbie
>
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
> <repositories>
> <repository>
> <id>staging</id>
> <url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
> </repository>
> </repositories>
>
> The dependency for the client itself would then be:
>
> <dependency>
> <groupId>org.apache.qpid</groupId>
> <artifactId>qpid-jms-client</artifactId>
> <version>0.20.0</version>
> </dependency>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
Tim Bish
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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Rob Godfrey <ro...@gmail.com>.
+1
Compiled, ran tests, tested against the Qpid Broker for Java
-- Rob
On 17 January 2017 at 10:49, Gordon Sim <gs...@redhat.com> wrote:
> On 16/01/17 18:38, Robbie Gemmell wrote:
>
>> Hi folks,
>>
>> I have put together a spin for a 0.20.0 Qpid JMS client release,
>> please test it and vote accordingly.
>>
>
> +1 (compiled, ran tests and then tested Helloworld and Sender/Receiver
> examples against qpid-cpp broker, dispatch router and python proton broker
> example).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [VOTE] Release Qpid JMS client 0.20.0
Posted by Gordon Sim <gs...@redhat.com>.
On 16/01/17 18:38, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a spin for a 0.20.0 Qpid JMS client release,
> please test it and vote accordingly.
+1 (compiled, ran tests and then tested Helloworld and Sender/Receiver
examples against qpid-cpp broker, dispatch router and python proton
broker example).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: versioning
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2017 at 11:54, Gordon Sim <gs...@redhat.com> wrote:
> On 17/01/17 10:47, Rob Godfrey wrote:
>>
>> I think there are effectively two "public APIs" in place here, the one
>> between the application and the library - which is essentially JMS 2.0,
>> and
>> so can never really change unless JMS does... and the interface between
>> the
>> client and the AMQP service. If that interface between the library and
>> the
>> AMQP service changes in a way that makes things incompatible, then it
>> would
>> mean that the client would not work against services which were compliant
>> with the specification. Since the mapping specification is still evolving
>> I think it is reasonable that we have an 0.x version at the moment...
>> however I would expect this to rapidly firm up.
>
>
> The mapping also affects brokers of course, e.g. ActiveMQ 5, ActiveMQ
> Artemis, the Qpid brokers etc. So while I'm not arguing that 0.x is
> *unreasonable*, I don't think the lack of a standardised mapping prevents
> the client choosing a >= 1.0 version either.
>
> Out of curiosity, are there any compatibility issues if using this new
> 0.20.0 release against older brokers that would not have been there with
> older versions of the client?
>
Nothing that I can think of. The changes are mostly new API for
existing features, new features the old brokers wont support (which
the client will indicate when attempting to use them), and internal
changes to support all of that.
>> I'll defer to Robbie/Tim who are more closely involved in the client work
>> to give their views on what they believe are the necessary conditions for
>> the client to hit a 1.0 release.
>
>
> Absolutely, I would also defer to those that are more involved! My initial
> comment on this was more of a general nature - i.e. that I think
> historically we have been too cautious about using the 'magic' 1.0 - rather
> than any criticism of the versioning or plans for JMS specifically.
>
>
> ---------------------------------------------------------------------
> 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: versioning
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2017 at 12:22, Adel Boutros <ad...@live.com> wrote:
> Indeed, from a corporate point of view, 1.0 and greater version does make us more comfortable than a 0.x which implies a work in progress.
>
> Speaking about versioning in general, I would like to ask the same question for Proton which is still at 0.16.0? We are going to put it in production soon and would like to know how far it is from a 1.x release.
>
Essentially the same answer, no current plan on this.
> I think these are the only 2 components still in 0.x version and providing some roadmap regarding a general public release would be benefitial for clients using these libraries.
>
Don't forget Dispatch :)
> Regards,
> Adel
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Tuesday, January 17, 2017 1:07:53 PM
> To: users@qpid.apache.org
> Subject: Re: versioning
>
> On 17 January 2017 at 12:54, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 17/01/17 10:47, Rob Godfrey wrote:
>>
>>> I think there are effectively two "public APIs" in place here, the one
>>> between the application and the library - which is essentially JMS 2.0,
>>> and
>>> so can never really change unless JMS does... and the interface between
>>> the
>>> client and the AMQP service. If that interface between the library and
>>> the
>>> AMQP service changes in a way that makes things incompatible, then it
>>> would
>>> mean that the client would not work against services which were compliant
>>> with the specification. Since the mapping specification is still evolving
>>> I think it is reasonable that we have an 0.x version at the moment...
>>> however I would expect this to rapidly firm up.
>>>
>>
>> The mapping also affects brokers of course, e.g. ActiveMQ 5, ActiveMQ
>> Artemis, the Qpid brokers etc. So while I'm not arguing that 0.x is
>> *unreasonable*, I don't think the lack of a standardised mapping prevents
>> the client choosing a >= 1.0 version either.
>>
>
> Indeed... I considered that as I typed my earlier reply... I think it would
> just be a little weird to have a 1.0 version which speaks some undefined
> in-progress version of the spec... kind of hard to pin down blame in the
> case of an incompatibility in that case. If we have a solid mapping doc
> which the client adheres to, and there is an incompatibility then blame
> should always be able to be pointed at the broker (as I trust Tim and
> Robbie to deliver a completely bug-free 1.0 client :-) ).
>
>
>>
>> Out of curiosity, are there any compatibility issues if using this new
>> 0.20.0 release against older brokers that would not have been there with
>> older versions of the client?
>
>
> I *think* and Robbie/Tim can correct me here, that most of the changes are
> "new" features that wouldn't have worked with older clients anyway.
> Between now and the full mapping spec finalisation, there is a chance that
> breaking changes will occur (though I would hope not).
>
>
>>
>>
>> I'll defer to Robbie/Tim who are more closely involved in the client work
>>> to give their views on what they believe are the necessary conditions for
>>> the client to hit a 1.0 release.
>>>
>>
>> Absolutely, I would also defer to those that are more involved! My initial
>> comment on this was more of a general nature - i.e. that I think
>> historically we have been too cautious about using the 'magic' 1.0 - rather
>> than any criticism of the versioning or plans for JMS specifically.
>>
>>
> 100% agree with you there... we took far too long to get to a 1.0... a
> number which has a magic significance in the corporate world :-). I would
> really like to see both us (Qpid) and OASIS (in practice, mostly us again)
> publish roadmaps for the JMS Mapping Spec and the JMS Client 1.0 release -
> with a targeted delivery date in the first half of this year. Perhaps we
> can talk about this soon ;-)
>
> -- Rob
>
>
>>
>> ---------------------------------------------------------------------
>> 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: versioning
Posted by Adel Boutros <ad...@live.com>.
Indeed, from a corporate point of view, 1.0 and greater version does make us more comfortable than a 0.x which implies a work in progress.
Speaking about versioning in general, I would like to ask the same question for Proton which is still at 0.16.0? We are going to put it in production soon and would like to know how far it is from a 1.x release.
I think these are the only 2 components still in 0.x version and providing some roadmap regarding a general public release would be benefitial for clients using these libraries.
Regards,
Adel
________________________________
From: Rob Godfrey <ro...@gmail.com>
Sent: Tuesday, January 17, 2017 1:07:53 PM
To: users@qpid.apache.org
Subject: Re: versioning
On 17 January 2017 at 12:54, Gordon Sim <gs...@redhat.com> wrote:
> On 17/01/17 10:47, Rob Godfrey wrote:
>
>> I think there are effectively two "public APIs" in place here, the one
>> between the application and the library - which is essentially JMS 2.0,
>> and
>> so can never really change unless JMS does... and the interface between
>> the
>> client and the AMQP service. If that interface between the library and
>> the
>> AMQP service changes in a way that makes things incompatible, then it
>> would
>> mean that the client would not work against services which were compliant
>> with the specification. Since the mapping specification is still evolving
>> I think it is reasonable that we have an 0.x version at the moment...
>> however I would expect this to rapidly firm up.
>>
>
> The mapping also affects brokers of course, e.g. ActiveMQ 5, ActiveMQ
> Artemis, the Qpid brokers etc. So while I'm not arguing that 0.x is
> *unreasonable*, I don't think the lack of a standardised mapping prevents
> the client choosing a >= 1.0 version either.
>
Indeed... I considered that as I typed my earlier reply... I think it would
just be a little weird to have a 1.0 version which speaks some undefined
in-progress version of the spec... kind of hard to pin down blame in the
case of an incompatibility in that case. If we have a solid mapping doc
which the client adheres to, and there is an incompatibility then blame
should always be able to be pointed at the broker (as I trust Tim and
Robbie to deliver a completely bug-free 1.0 client :-) ).
>
> Out of curiosity, are there any compatibility issues if using this new
> 0.20.0 release against older brokers that would not have been there with
> older versions of the client?
I *think* and Robbie/Tim can correct me here, that most of the changes are
"new" features that wouldn't have worked with older clients anyway.
Between now and the full mapping spec finalisation, there is a chance that
breaking changes will occur (though I would hope not).
>
>
> I'll defer to Robbie/Tim who are more closely involved in the client work
>> to give their views on what they believe are the necessary conditions for
>> the client to hit a 1.0 release.
>>
>
> Absolutely, I would also defer to those that are more involved! My initial
> comment on this was more of a general nature - i.e. that I think
> historically we have been too cautious about using the 'magic' 1.0 - rather
> than any criticism of the versioning or plans for JMS specifically.
>
>
100% agree with you there... we took far too long to get to a 1.0... a
number which has a magic significance in the corporate world :-). I would
really like to see both us (Qpid) and OASIS (in practice, mostly us again)
publish roadmaps for the JMS Mapping Spec and the JMS Client 1.0 release -
with a targeted delivery date in the first half of this year. Perhaps we
can talk about this soon ;-)
-- Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: versioning
Posted by Rob Godfrey <ro...@gmail.com>.
On 17 January 2017 at 12:54, Gordon Sim <gs...@redhat.com> wrote:
> On 17/01/17 10:47, Rob Godfrey wrote:
>
>> I think there are effectively two "public APIs" in place here, the one
>> between the application and the library - which is essentially JMS 2.0,
>> and
>> so can never really change unless JMS does... and the interface between
>> the
>> client and the AMQP service. If that interface between the library and
>> the
>> AMQP service changes in a way that makes things incompatible, then it
>> would
>> mean that the client would not work against services which were compliant
>> with the specification. Since the mapping specification is still evolving
>> I think it is reasonable that we have an 0.x version at the moment...
>> however I would expect this to rapidly firm up.
>>
>
> The mapping also affects brokers of course, e.g. ActiveMQ 5, ActiveMQ
> Artemis, the Qpid brokers etc. So while I'm not arguing that 0.x is
> *unreasonable*, I don't think the lack of a standardised mapping prevents
> the client choosing a >= 1.0 version either.
>
Indeed... I considered that as I typed my earlier reply... I think it would
just be a little weird to have a 1.0 version which speaks some undefined
in-progress version of the spec... kind of hard to pin down blame in the
case of an incompatibility in that case. If we have a solid mapping doc
which the client adheres to, and there is an incompatibility then blame
should always be able to be pointed at the broker (as I trust Tim and
Robbie to deliver a completely bug-free 1.0 client :-) ).
>
> Out of curiosity, are there any compatibility issues if using this new
> 0.20.0 release against older brokers that would not have been there with
> older versions of the client?
I *think* and Robbie/Tim can correct me here, that most of the changes are
"new" features that wouldn't have worked with older clients anyway.
Between now and the full mapping spec finalisation, there is a chance that
breaking changes will occur (though I would hope not).
>
>
> I'll defer to Robbie/Tim who are more closely involved in the client work
>> to give their views on what they believe are the necessary conditions for
>> the client to hit a 1.0 release.
>>
>
> Absolutely, I would also defer to those that are more involved! My initial
> comment on this was more of a general nature - i.e. that I think
> historically we have been too cautious about using the 'magic' 1.0 - rather
> than any criticism of the versioning or plans for JMS specifically.
>
>
100% agree with you there... we took far too long to get to a 1.0... a
number which has a magic significance in the corporate world :-). I would
really like to see both us (Qpid) and OASIS (in practice, mostly us again)
publish roadmaps for the JMS Mapping Spec and the JMS Client 1.0 release -
with a targeted delivery date in the first half of this year. Perhaps we
can talk about this soon ;-)
-- Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: versioning
Posted by Gordon Sim <gs...@redhat.com>.
On 17/01/17 10:47, Rob Godfrey wrote:
> I think there are effectively two "public APIs" in place here, the one
> between the application and the library - which is essentially JMS 2.0, and
> so can never really change unless JMS does... and the interface between the
> client and the AMQP service. If that interface between the library and the
> AMQP service changes in a way that makes things incompatible, then it would
> mean that the client would not work against services which were compliant
> with the specification. Since the mapping specification is still evolving
> I think it is reasonable that we have an 0.x version at the moment...
> however I would expect this to rapidly firm up.
The mapping also affects brokers of course, e.g. ActiveMQ 5, ActiveMQ
Artemis, the Qpid brokers etc. So while I'm not arguing that 0.x is
*unreasonable*, I don't think the lack of a standardised mapping
prevents the client choosing a >= 1.0 version either.
Out of curiosity, are there any compatibility issues if using this new
0.20.0 release against older brokers that would not have been there with
older versions of the client?
> I'll defer to Robbie/Tim who are more closely involved in the client work
> to give their views on what they believe are the necessary conditions for
> the client to hit a 1.0 release.
Absolutely, I would also defer to those that are more involved! My
initial comment on this was more of a general nature - i.e. that I think
historically we have been too cautious about using the 'magic' 1.0 -
rather than any criticism of the versioning or plans for JMS specifically.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: versioning
Posted by Rob Godfrey <ro...@gmail.com>.
On 17 January 2017 at 11:37, Adel Boutros <Ad...@live.com> wrote:
> Hello,
>
>
> If I understand correctly, you are in a way mapping the JMS release cycle
> to the AMQP support and the JMS specs. So 0.x is still used because support
> form AQM 1.0 is not done yet and when it will be, you will release JMS
> client 1.0.
>
> That not any sort of official policy, more my view of one reason we might
be considering to hold off declaring a version 1.0.
>
> However, in my humble opinion, your API is public and very widely used. My
> question was founded on the semantic versioning as defined here (
> http://semver.org/).
>
> This is why I think 1.0.0 should be already the case for JMS Client.
>
>
I think there are effectively two "public APIs" in place here, the one
between the application and the library - which is essentially JMS 2.0, and
so can never really change unless JMS does... and the interface between the
client and the AMQP service. If that interface between the library and the
AMQP service changes in a way that makes things incompatible, then it would
mean that the client would not work against services which were compliant
with the specification. Since the mapping specification is still evolving
I think it is reasonable that we have an 0.x version at the moment...
however I would expect this to rapidly firm up.
I'll defer to Robbie/Tim who are more closely involved in the client work
to give their views on what they believe are the necessary conditions for
the client to hit a 1.0 release.
I would definitely like to get us to commit to a 1.0 release this year -
and preferably fairly early in the year - but the folks actually working on
this will need to be the ones making the call here.
-- Rob
> In case you have major work which will break the current API, then why not
> simply release a 2.0.0?
>
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Tuesday, January 17, 2017 11:10:41 AM
> To: users@qpid.apache.org
> Subject: Re: versioning
>
> On 17 January 2017 at 09:49, Gordon Sim <gs...@redhat.com> wrote:
> > On 16/01/17 20:38, Timothy Bish wrote:
> >>
> >> There are no plans for a 1.0.0 release at this time.
> >
> >
> > Qpid has historically been reluctant to go to a 1.0 for different
> reasons.
> > One was the desire to wait for AMQP 1.0 (which took a long time to come,
> but
> > has now been an ISO standard form a long time). Another was in case the
> API
> > needed to change. For JMS this wouldn't really be an issue I wouldn't
> think.
> >
> > So while I have no objection to the current version number, I think we
> > should not be afraid to move to a 1.0 or beyond. It doesn't mean there
> are
> > no more bugs, but it does I think more accurately indicate the level of
> > completeness and robustness.
> >
>
> I now see Rob has just beaten me to saying essentially the same thing,
> but since I already typed it...
>
> I think Tim simply meant we have not recently thought on when we might
> do so, i.e. there are no plans, not that we never intend to or couldnt
> decide to do so tomorrow if we wanted.
>
> We have just changed the API version, and the mapping of certain
> behaviours has not yet been finalised, so there are reasons I don't
> actually think its entirely out of place for it to still be at 0.X so
> far.
>
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: versioning
Posted by Adel Boutros <Ad...@live.com>.
Hello,
If I understand correctly, you are in a way mapping the JMS release cycle to the AMQP support and the JMS specs. So 0.x is still used because support form AQM 1.0 is not done yet and when it will be, you will release JMS client 1.0.
However, in my humble opinion, your API is public and very widely used. My question was founded on the semantic versioning as defined here (http://semver.org/).
This is why I think 1.0.0 should be already the case for JMS Client.
In case you have major work which will break the current API, then why not simply release a 2.0.0?
Regards,
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Tuesday, January 17, 2017 11:10:41 AM
To: users@qpid.apache.org
Subject: Re: versioning
On 17 January 2017 at 09:49, Gordon Sim <gs...@redhat.com> wrote:
> On 16/01/17 20:38, Timothy Bish wrote:
>>
>> There are no plans for a 1.0.0 release at this time.
>
>
> Qpid has historically been reluctant to go to a 1.0 for different reasons.
> One was the desire to wait for AMQP 1.0 (which took a long time to come, but
> has now been an ISO standard form a long time). Another was in case the API
> needed to change. For JMS this wouldn't really be an issue I wouldn't think.
>
> So while I have no objection to the current version number, I think we
> should not be afraid to move to a 1.0 or beyond. It doesn't mean there are
> no more bugs, but it does I think more accurately indicate the level of
> completeness and robustness.
>
I now see Rob has just beaten me to saying essentially the same thing,
but since I already typed it...
I think Tim simply meant we have not recently thought on when we might
do so, i.e. there are no plans, not that we never intend to or couldnt
decide to do so tomorrow if we wanted.
We have just changed the API version, and the mapping of certain
behaviours has not yet been finalised, so there are reasons I don't
actually think its entirely out of place for it to still be at 0.X so
far.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: versioning
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2017 at 09:49, Gordon Sim <gs...@redhat.com> wrote:
> On 16/01/17 20:38, Timothy Bish wrote:
>>
>> There are no plans for a 1.0.0 release at this time.
>
>
> Qpid has historically been reluctant to go to a 1.0 for different reasons.
> One was the desire to wait for AMQP 1.0 (which took a long time to come, but
> has now been an ISO standard form a long time). Another was in case the API
> needed to change. For JMS this wouldn't really be an issue I wouldn't think.
>
> So while I have no objection to the current version number, I think we
> should not be afraid to move to a 1.0 or beyond. It doesn't mean there are
> no more bugs, but it does I think more accurately indicate the level of
> completeness and robustness.
>
I now see Rob has just beaten me to saying essentially the same thing,
but since I already typed it...
I think Tim simply meant we have not recently thought on when we might
do so, i.e. there are no plans, not that we never intend to or couldnt
decide to do so tomorrow if we wanted.
We have just changed the API version, and the mapping of certain
behaviours has not yet been finalised, so there are reasons I don't
actually think its entirely out of place for it to still be at 0.X so
far.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: versioning
Posted by Rob Godfrey <ro...@gmail.com>.
I must admit that I took Tim's comment (after a moment of reflection) as
meaning "we haven't finalised the timeline for our 1.0 release yet" rather
than "we don't have any plans to ever release to 1.0".
The only potential external pre-condition we might lace on a 1.0 release is
the completion of the AMQP <-> JMS mapping work at OASIS, such that we know
we are not going to have to make breaking changes to be in line with that
specification. Even there I think we can be (much) less cautious than we
were with AMQP 1.0.
Since members from the Qpid community are the primary contributors to the
OASIS mappng effort, I think we should set ourselves a target for the
completion of that work, and also to releasing a 1.0 version of the client
within the same timeframe (and that being within this calendar year).
-- Rob
On 17 January 2017 at 10:49, Gordon Sim <gs...@redhat.com> wrote:
> On 16/01/17 20:38, Timothy Bish wrote:
>
>> There are no plans for a 1.0.0 release at this time.
>>
>
> Qpid has historically been reluctant to go to a 1.0 for different reasons.
> One was the desire to wait for AMQP 1.0 (which took a long time to come,
> but has now been an ISO standard form a long time). Another was in case the
> API needed to change. For JMS this wouldn't really be an issue I wouldn't
> think.
>
> So while I have no objection to the current version number, I think we
> should not be afraid to move to a 1.0 or beyond. It doesn't mean there are
> no more bugs, but it does I think more accurately indicate the level of
> completeness and robustness.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
versioning
Posted by Gordon Sim <gs...@redhat.com>.
On 16/01/17 20:38, Timothy Bish wrote:
> There are no plans for a 1.0.0 release at this time.
Qpid has historically been reluctant to go to a 1.0 for different
reasons. One was the desire to wait for AMQP 1.0 (which took a long time
to come, but has now been an ISO standard form a long time). Another was
in case the API needed to change. For JMS this wouldn't really be an
issue I wouldn't think.
So while I have no objection to the current version number, I think we
should not be afraid to move to a 1.0 or beyond. It doesn't mean there
are no more bugs, but it does I think more accurately indicate the level
of completeness and robustness.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [VOTE] Release Qpid JMS client 0.20.0
Posted by Robbie Gemmell <ro...@gmail.com>.
On 16 January 2017 at 20:38, Timothy Bish <ta...@gmail.com> wrote:
> On 01/16/2017 02:29 PM, Adel Boutros wrote:
>>
>> Hello Robbie,
>>
>>
>> Out of curiosity, can you please explain why the release is 0.20.0 and not
>> 0.12.0?
>>
>> When will an official 1.0.0 be out?
>
>
> The main reason for the bump is that this version now implements the JMS 2.0
> API and is therefore a larger shift in features and code changes that a
> version 0.12.0 would imply.
>
> There are no plans for a 1.0.0 release at this time.
>
>
Another reason was that it was always going to take some months to
complete the new work, and it wasn't clear whether we might need or
want to do additional releases on the existing release line during
that time, so I left a gap to facilitate doing so rather than needing
to bump master each time. In the end we only did one such release.
>>
>> Regards,
>>
>> Adel
>>
>> ________________________________
>> From: Robbie Gemmell <ro...@gmail.com>
>> Sent: Monday, January 16, 2017 7:38:04 PM
>> To: users@qpid.apache.org
>> Subject: [VOTE] Release Qpid JMS client 0.20.0
>>
>> Hi folks,
>>
>> I have put together a spin for a 0.20.0 Qpid JMS client release,
>> please test it and vote accordingly.
>>
>> The source and binary archives can be grabbed from:
>> https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>>
>> Those files and the other maven artifacts are also staged for now at:
>> https://repository.apache.org/content/repositories/orgapacheqpid-1097
>>
>> Regards,
>> Robbie
>>
>>
>> P.S. If you want to test it out using maven (e.g with the examples
>> src, or your own things), you can temporarily add this to your poms to
>> access the staging repo:
>>
>> <repositories>
>> <repository>
>> <id>staging</id>
>>
>> <url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
>> </repository>
>> </repositories>
>>
>> The dependency for the client itself would then be:
>>
>> <dependency>
>> <groupId>org.apache.qpid</groupId>
>> <artifactId>qpid-jms-client</artifactId>
>> <version>0.20.0</version>
>> </dependency>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
>
> --
> Tim Bish
> 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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Timothy Bish <ta...@gmail.com>.
On 01/16/2017 02:29 PM, Adel Boutros wrote:
> Hello Robbie,
>
>
> Out of curiosity, can you please explain why the release is 0.20.0 and not 0.12.0?
>
> When will an official 1.0.0 be out?
The main reason for the bump is that this version now implements the JMS
2.0 API and is therefore a larger shift in features and code changes
that a version 0.12.0 would imply.
There are no plans for a 1.0.0 release at this time.
>
> Regards,
>
> Adel
>
> ________________________________
> From: Robbie Gemmell <ro...@gmail.com>
> Sent: Monday, January 16, 2017 7:38:04 PM
> To: users@qpid.apache.org
> Subject: [VOTE] Release Qpid JMS client 0.20.0
>
> Hi folks,
>
> I have put together a spin for a 0.20.0 Qpid JMS client release,
> please test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1097
>
> Regards,
> Robbie
>
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
> <repositories>
> <repository>
> <id>staging</id>
> <url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
> </repository>
> </repositories>
>
> The dependency for the client itself would then be:
>
> <dependency>
> <groupId>org.apache.qpid</groupId>
> <artifactId>qpid-jms-client</artifactId>
> <version>0.20.0</version>
> </dependency>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
Tim Bish
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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Adel Boutros <Ad...@live.com>.
Hello Robbie,
Out of curiosity, can you please explain why the release is 0.20.0 and not 0.12.0?
When will an official 1.0.0 be out?
Regards,
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Monday, January 16, 2017 7:38:04 PM
To: users@qpid.apache.org
Subject: [VOTE] Release Qpid JMS client 0.20.0
Hi folks,
I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.
The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097
Regards,
Robbie
P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:
<repositories>
<repository>
<id>staging</id>
<url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
</repository>
</repositories>
The dependency for the client itself would then be:
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-jms-client</artifactId>
<version>0.20.0</version>
</dependency>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [VOTE] Release Qpid JMS client 0.20.0
Posted by Lorenz Quack <qu...@gmail.com>.
+1
* validated the checksums
* built from source & ran tests
* ran Hello World example against Qpid Broker for Java 6.1.1
On 16/01/17 18:38, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a spin for a 0.20.0 Qpid JMS client release,
> please test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1097
>
> Regards,
> Robbie
>
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
> <repositories>
> <repository>
> <id>staging</id>
> <url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
> </repository>
> </repositories>
>
> The dependency for the client itself would then be:
>
> <dependency>
> <groupId>org.apache.qpid</groupId>
> <artifactId>qpid-jms-client</artifactId>
> <version>0.20.0</version>
> </dependency>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Oleksandr Rudyy <or...@gmail.com>.
+1
I tested shared subscription functionality against WIP shared
subscription support for Java Broker. No issue is found so far.
On 18 January 2017 at 14:41, Keith W <ke...@gmail.com> wrote:
> +1
>
> * verify the checksums and signatures
> * ran apache rat-check
> * built from source distribution artefact and ran all tests (mvn
> verify with Java 1.8.0_111 on Mac OS X 10.11.6)
> * ran Joram JMS integration tests against the Java Broker (trunk and
> 6.1.1) using the staged Maven artefacts
>
> On 17 January 2017 at 19:40, Jakub Scholz <ja...@scholz.cz> wrote:
>> +1 ... I used the staged artefacts and run my tests against the C++ broker.
>>
>> On Tue, Jan 17, 2017 at 2:20 PM, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> On 16 January 2017 at 18:38, Robbie Gemmell <ro...@gmail.com>
>>> wrote:
>>> > Hi folks,
>>> >
>>> > I have put together a spin for a 0.20.0 Qpid JMS client release,
>>> > please test it and vote accordingly.
>>> >
>>> > The source and binary archives can be grabbed from:
>>> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>>> >
>>> > Those files and the other maven artifacts are also staged for now at:
>>> > https://repository.apache.org/content/repositories/orgapacheqpid-1097
>>> >
>>> > Regards,
>>> > Robbie
>>> >
>>> >
>>> > P.S. If you want to test it out using maven (e.g with the examples
>>> > src, or your own things), you can temporarily add this to your poms to
>>> > access the staging repo:
>>> >
>>> > <repositories>
>>> > <repository>
>>> > <id>staging</id>
>>> > <url>https://repository.apache.org/content/
>>> repositories/orgapacheqpid-1097</url>
>>> > </repository>
>>> > </repositories>
>>> >
>>> > The dependency for the client itself would then be:
>>> >
>>> > <dependency>
>>> > <groupId>org.apache.qpid</groupId>
>>> > <artifactId>qpid-jms-client</artifactId>
>>> > <version>0.20.0</version>
>>> > </dependency>
>>>
>>> Making my +1 explicit
>>>
>>> I tested things out as follows:
>>> - Verified the checksum and signature files.
>>> - Checked LICENCE+NOTICE files present/correct.
>>> - Ran mvn apache-rat:check to verify licence headers.
>>> - Ran the build+tests from the source release archive, no issues.
>>> - Built the examples from the binary release archive using maven and
>>> ran against Qpid Dispatch master, Qpid CPP master (both built against
>>> Qpid Proton master), Qpid for Java master, ActiveMQ 5 master, and
>>> ActiveMQ Artemis master.
>>> - Built the examples using javac manually and run to verify required
>>> libs included in lib dir.
>>> - Ran the Joram JMS tests against the Qpid for Java master using the
>>> staging repo.
>>> - Ran the ActiveMQ 5 master tests using the staging repo.
>>>
>>> Robbie
>>>
>>> ---------------------------------------------------------------------
>>> 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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Keith W <ke...@gmail.com>.
+1
* verify the checksums and signatures
* ran apache rat-check
* built from source distribution artefact and ran all tests (mvn
verify with Java 1.8.0_111 on Mac OS X 10.11.6)
* ran Joram JMS integration tests against the Java Broker (trunk and
6.1.1) using the staged Maven artefacts
On 17 January 2017 at 19:40, Jakub Scholz <ja...@scholz.cz> wrote:
> +1 ... I used the staged artefacts and run my tests against the C++ broker.
>
> On Tue, Jan 17, 2017 at 2:20 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 16 January 2017 at 18:38, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>> > Hi folks,
>> >
>> > I have put together a spin for a 0.20.0 Qpid JMS client release,
>> > please test it and vote accordingly.
>> >
>> > The source and binary archives can be grabbed from:
>> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>> >
>> > Those files and the other maven artifacts are also staged for now at:
>> > https://repository.apache.org/content/repositories/orgapacheqpid-1097
>> >
>> > Regards,
>> > Robbie
>> >
>> >
>> > P.S. If you want to test it out using maven (e.g with the examples
>> > src, or your own things), you can temporarily add this to your poms to
>> > access the staging repo:
>> >
>> > <repositories>
>> > <repository>
>> > <id>staging</id>
>> > <url>https://repository.apache.org/content/
>> repositories/orgapacheqpid-1097</url>
>> > </repository>
>> > </repositories>
>> >
>> > The dependency for the client itself would then be:
>> >
>> > <dependency>
>> > <groupId>org.apache.qpid</groupId>
>> > <artifactId>qpid-jms-client</artifactId>
>> > <version>0.20.0</version>
>> > </dependency>
>>
>> Making my +1 explicit
>>
>> I tested things out as follows:
>> - Verified the checksum and signature files.
>> - Checked LICENCE+NOTICE files present/correct.
>> - Ran mvn apache-rat:check to verify licence headers.
>> - Ran the build+tests from the source release archive, no issues.
>> - Built the examples from the binary release archive using maven and
>> ran against Qpid Dispatch master, Qpid CPP master (both built against
>> Qpid Proton master), Qpid for Java master, ActiveMQ 5 master, and
>> ActiveMQ Artemis master.
>> - Built the examples using javac manually and run to verify required
>> libs included in lib dir.
>> - Ran the Joram JMS tests against the Qpid for Java master using the
>> staging repo.
>> - Ran the ActiveMQ 5 master tests using the staging repo.
>>
>> Robbie
>>
>> ---------------------------------------------------------------------
>> 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: [VOTE] Release Qpid JMS client 0.20.0
Posted by Jakub Scholz <ja...@scholz.cz>.
+1 ... I used the staged artefacts and run my tests against the C++ broker.
On Tue, Jan 17, 2017 at 2:20 PM, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 16 January 2017 at 18:38, Robbie Gemmell <ro...@gmail.com>
> wrote:
> > Hi folks,
> >
> > I have put together a spin for a 0.20.0 Qpid JMS client release,
> > please test it and vote accordingly.
> >
> > The source and binary archives can be grabbed from:
> > https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
> >
> > Those files and the other maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1097
> >
> > Regards,
> > Robbie
> >
> >
> > P.S. If you want to test it out using maven (e.g with the examples
> > src, or your own things), you can temporarily add this to your poms to
> > access the staging repo:
> >
> > <repositories>
> > <repository>
> > <id>staging</id>
> > <url>https://repository.apache.org/content/
> repositories/orgapacheqpid-1097</url>
> > </repository>
> > </repositories>
> >
> > The dependency for the client itself would then be:
> >
> > <dependency>
> > <groupId>org.apache.qpid</groupId>
> > <artifactId>qpid-jms-client</artifactId>
> > <version>0.20.0</version>
> > </dependency>
>
> Making my +1 explicit
>
> I tested things out as follows:
> - Verified the checksum and signature files.
> - Checked LICENCE+NOTICE files present/correct.
> - Ran mvn apache-rat:check to verify licence headers.
> - Ran the build+tests from the source release archive, no issues.
> - Built the examples from the binary release archive using maven and
> ran against Qpid Dispatch master, Qpid CPP master (both built against
> Qpid Proton master), Qpid for Java master, ActiveMQ 5 master, and
> ActiveMQ Artemis master.
> - Built the examples using javac manually and run to verify required
> libs included in lib dir.
> - Ran the Joram JMS tests against the Qpid for Java master using the
> staging repo.
> - Ran the ActiveMQ 5 master tests using the staging repo.
>
> Robbie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [VOTE] Release Qpid JMS client 0.20.0
Posted by Robbie Gemmell <ro...@gmail.com>.
On 16 January 2017 at 18:38, Robbie Gemmell <ro...@gmail.com> wrote:
> Hi folks,
>
> I have put together a spin for a 0.20.0 Qpid JMS client release,
> please test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1097
>
> Regards,
> Robbie
>
>
> P.S. If you want to test it out using maven (e.g with the examples
> src, or your own things), you can temporarily add this to your poms to
> access the staging repo:
>
> <repositories>
> <repository>
> <id>staging</id>
> <url>https://repository.apache.org/content/repositories/orgapacheqpid-1097</url>
> </repository>
> </repositories>
>
> The dependency for the client itself would then be:
>
> <dependency>
> <groupId>org.apache.qpid</groupId>
> <artifactId>qpid-jms-client</artifactId>
> <version>0.20.0</version>
> </dependency>
Making my +1 explicit
I tested things out as follows:
- Verified the checksum and signature files.
- Checked LICENCE+NOTICE files present/correct.
- Ran mvn apache-rat:check to verify licence headers.
- Ran the build+tests from the source release archive, no issues.
- Built the examples from the binary release archive using maven and
ran against Qpid Dispatch master, Qpid CPP master (both built against
Qpid Proton master), Qpid for Java master, ActiveMQ 5 master, and
ActiveMQ Artemis master.
- Built the examples using javac manually and run to verify required
libs included in lib dir.
- Ran the Joram JMS tests against the Qpid for Java master using the
staging repo.
- Ran the ActiveMQ 5 master tests using the staging repo.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org