I dont really understand what your table of combinations entries say,
and so why Option 1 would be to support "3 (or more)" LTS branches but
the other only 2, so its hard to reply specifically around that.
Adding -javax modules on a new branch thats primary-jakarta just
doesnt really make sense to
I had assumed you would use Spring 6 on the Jakarta branch, though
still targeting 11 with the client etc, but requiring 17 for build and
using those modules with spring 6 requirement (im not clear which bits
those are...but sounds like its more widespread than I thought it
was).
On Wed, 5 Apr 202
I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client
module in 5.18.x. It provides runway for users that lag on JDK adoption and are
not using Spring 6.
A couple of technical notes to keep in mind about JDK-Spring-Jakarta coupling
*specific* to ActiveMQ 5:
1. Spring 6 sup
All fair points Robbie. I'd still like to leave the jakarta client in
5.18.x just as it gives some compatibility for clients only even if it's
going to go away in 5.19.x.
So how about the following:
5.18.x - Still javax support with just a jakarta client. This can be a long
term LTS, at least for
No extra -javax client module module. People wanting Jakarta client
support would use 5.19.x. People wanting javax client support would
just use 5.18.x as they would today. I'd even consider removing the
extra 5.18.x -jakarta client module personally (could be super nice
and add a maven relocation
So if 5.19.x just becomes Jakarta API (and not new modules) then I assume
we would just have an extra client module for javax? Basically the inverse
of 5.18.x (where we primarily use javax and have a jakarta client module)
I guess that will be fine but it is pretty unusual to make such a large
bre
Hi
Agree, it was basically my proposal in a previous email: I would not
use different artifacts, just change to the major version (5.19.x). If
people still want to use javax.jms, then he can use 5.18.x (that we
can "flag" as LTS).
Regards
JB
On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon
w