You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2017/01/17 09:49:32 UTC
versioning
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: 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
>
>