On 9 January 2017 at 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 c
+1 for dropping support for java7
I agree with Keith that splitting java broker and client requires a
separate discussion. I would prefer an approach where 2 separate projects
are created first. Releasing of bugfix client versions from 6.1 branch
might not be convenient because client and broker s
>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
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 wrote:
>> so doing so at
> 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 app
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
+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
for
+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 VersionFirst ReleaseEnd of Public Updates
7Jul 2011Apr 2015
8Mar 2014Sep 2017 o
They are indeed, those are among the various builds using Proton that
I know have made the switch (though only Artemis has already been
released since then I believe, with 5.15.0 still needing to actually
go out before ActiveMQ 5 completes its transition )
On 9 January 2017 at 22:30, Clebert Sucon
Yep.
Robbie
On 9 January 2017 at 23:28, Jakub Scholz wrote:
> Sounds reasonable to me. I guess that as always ... in case it would be
> needed we can have some patch releases for some critical bugs or security
> issues.
>
> Jakub
>
>
> On Mon, Jan 9, 2017 at 11:28 PM, Robbie Gemmell
> wrote:
>
Sounds reasonable to me. I guess that as always ... in case it would be
needed we can have some patch releases for some critical bugs or security
issues.
Jakub
On Mon, Jan 9, 2017 at 11:28 PM, Robbie Gemmell
wrote:
> I'd like to propose dropping support for Java 7 in the broker and both
> JMS
+1. We have had a similar discussion on ActiveMQ some time ago, and
AFAIK both Artemis and ActiveMQ are Java8+ now.
On Mon, Jan 9, 2017 at 5:28 PM, 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.
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 i
13 matches
Mail list logo
