Yep, I can certainly see it is the far easier approach, and removing it and common from 7.x should make things fairly simple in terms of having the two versions working in a JVM going forward (e.g for verification testing).
Robbie On 10 January 2017 at 11:48, Rob Godfrey <[email protected]> wrote: >> so doing so at this point might not outweigh the effort required. > > That's really what triggered this train of thought. We'd like to separate > out the client and the broker, however at this point it its life the 0-x > client is really only receiving maintenance changes, and they are anyway > being applied to the 6.1.x branch (and 6.0.x branch). As such I think it > might be easier all round if we just say that the 7.x broker is verified > against the 6.1.x client. And for 7.0.x we can get rid of the client (and > common) from the Qpid for Java release. > > -- Rob > > > On 10 January 2017 at 12:38, Robbie Gemmell <[email protected]> > wrote: > >> I'd maybe suggest splitting the 0-x client out on its own instead >> rather than just leaving it as part of 6.1.x, though thats not >> necessarily as simple as it sounds which is likely why it hasn't been >> done already, so doing so at this point might not outweigh the effort >> required. >> >> On 10 January 2017 at 11:05, Rob Godfrey <[email protected]> wrote: >> > +1 To removing Java 7 support in the Broker for Java and the JMS client. >> > >> > On the AMQP 0-x JMS client my inclination is to say that we actually >> remove >> > this client from future feature releases. Maintenance releases on the >> > 6.1.x branch will continue to support Java 7 (and 8, of course), but >> going >> > forward the AMQP 1.0 JMS client should be the only supported JMS library. >> > (Since I don't think anyone is actually planning on adding any features >> to >> > the 0-x client, I don't think this is actually as big a deal as it might >> > initially sound - we'd verify the compatibility between the 7.0 Broker >> and >> > the v6.x AMQP 0-x JMS client, of course) >> > >> > -- Rob >> > >> > On 10 January 2017 at 10:08, Lorenz Quack <[email protected]> >> wrote: >> > >> >> +1 >> >> >> >> The next Qpid Broker for Java is probably going to be 7.0 (i.e., a major >> >> release) so now is as good a time as any. >> >> >> >> Some dates for reference [1]: >> >> Java Version First Release End of Public Updates >> >> 7 Jul 2011 Apr 2015 >> >> 8 Mar 2014 Sep 2017 or later >> >> >> >> [1] http://www.oracle.com/technetwork/java/eol-135779.html >> >> >> >> >> >> >> >> On 09/01/17 22:28, Robbie Gemmell wrote: >> >> >> >>> I'd like to propose dropping support for Java 7 in the broker and both >> >>> JMS clients in their next significant new releases. >> >>> >> >>> Almost a year ago, there was a proposal around preparing to end >> >>> support for Java 7 in the broker and AMQP 0-x JMS client, with the the >> >>> idea of doing a ~Q3 2016 major release in which the broker required >> >>> Java 8, followed by a minor follow-up release in 2017 that then >> >>> dropped support for the client. I believe both still currently retain >> >>> support for Java 7. >> >>> >> >>> I agreed with the proposal and suggested something similar made sense >> >>> for the AMQP 1.0 JMS client, and I think it is time we made that >> >>> change. I think it would be appropriate to do so in concert with the >> >>> 0.20.0 release the client is now ready for, and plan to do so unless >> >>> convinced otherwise. >> >>> >> >>> While on the Java 7 subject: I'm a little more neutral about Proton-J, >> >>> and wouldn't be that opposed to it continuing to for a bit longer, >> >>> although probably not all that long, as the majority of builds I know >> >>> of personally that depend on it already require Java 8, some doing so >> >>> before Proton even dropped its Java 6 support in 2015 (after Java 7 >> >>> went EOL). >> >>> >> >>> Robbie >> >>> >> >>> --------------------------------------------------------------------- >> >>> 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] >> >> >> >> >> >> --------------------------------------------------------------------- >> 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]
