qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: versioning
Date Tue, 17 Jan 2017 12:07:53 GMT
On 17 January 2017 at 12:54, Gordon Sim <gsim@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message