On 17 January 2017 at 12:22, Adel Boutros <[email protected]> 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 <[email protected]> > Sent: Tuesday, January 17, 2017 1:07:53 PM > To: [email protected] > Subject: Re: versioning > > On 17 January 2017 at 12:54, Gordon Sim <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
