>I'd like to propose dropping support for Java 7 in the broker and both >JMS clients in their next significant new releases.
+1 Rob - I like the idea for a 0-x JMS client removal from trunk and managing maintenance from 6.1.x, but think it warrants a separate DISCUSS thread. On 10 January 2017 at 12:11, Robbie Gemmell <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
