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: [email protected] For additional commands, e-mail: [email protected]
