Hi all, Back from vacation, hopefully not to late for feedback.
Thanks Chris for bringing the discussion up. I agree that we should now favor 6.x and set the EOL date for 5.x As JB mentioned, I don't think there is a need to shade the client jar to bring it to javax namespace. The client is thin and selfcontained pretty much and there aren't any CVEs usually affecting it directly. So using an old javax client is fine with me. So I'm +1 as well Hopefully that should give contributors some cycles to work on the project features as opposed to backporting and doing releases on old versions. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, Jul 17, 2026 at 11:03 PM Jamie G. <[email protected]> wrote: > I think the direction is reasonable. +1 > > On Fri, Jul 17, 2026 at 10:37 Christopher Shannon < > [email protected]> wrote: > > > Does anyone else have anymore thoughts on this? > > > > On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon > > <[email protected]> wrote: > > > > > > Hi JB, > > > > > > That's fine with me to only support Jakarta, as I said in my email > > > that's my preference. I don't really want to support javax at all in > > > 6.x and I'm in favor of dropping it, I just brought it up as an option > > > to see what others think. > > > > > > I think it's reasonable for people to just use the 5.x client because > > > the client has very few dependencies and doesn't change often. > > > > > > I think once 6.3.0 is out we should no longer be backporting anything > > > new to 5.19.x, i.e. no new flags or features or anything. All of that > > > needs to stop. Anything backported going forward should be limited > > > strictly to bug fixes and then further reduce it to only important > > > security fixes at some point. But as soon as we drop it entirely I > > > think the better because it's holding up modernization. > > > > > > Chris > > > > > > > > > On Fri, Jul 10, 2026 at 12:28 AM Jean-Baptiste Onofré <[email protected] > > > > wrote: > > > > > > > > Hi > > > > > > > > I think we discussed that in the past and the plan (as I recall) was > to > > > > stop working on 5.19.x when 6.3.0 will be out. > > > > > > > > I don't think we still need to support the javax client because: > > people can > > > > still use the latest 5.19.x version, even if it's not active, the > > artifacts > > > > are still available for use. > > > > > > > > Personally, I would just announce that 5.19.x is not active anymore, > > and > > > > people have to use 6.x. > > > > If we still provide javax support on 6.x (with another project), > users > > will > > > > just stay with it forever. > > > > > > > > I would rather propose the following: > > > > 1. 5.19.x won't be active anymore when 6.3.0 will be out. I'm fine to > > give > > > > more time (up to 6.4.0 for instance), but not javax support in 6.x. > > > > 2. users can still use javax / 5.19.x > > > > 3. focus on the 6.x series > > > > > > > > I think 6.3.0 is pretty close (I'm resuming several working items for > > this > > > > release). Jetty 12 is still needed. Matt is working on it: if we > don't > > have > > > > it soon, I will give a hand on that. > > > > > > > > So -1 for javax client, simply. > > > > > > > > Regards > > > > JB > > > > > > > > On Thu, Jul 9, 2026 at 7:40 PM Christopher Shannon < > > > > [email protected]> wrote: > > > > > > > > > I think it's time to discuss a timeline to officially end support > for > > > > > 5.19.x and all other 5.x releases. > > > > > > > > > > There are many reasons for EOL including: > > > > > > > > > > 1. Security: Because 5.x is still using javax we are unable to > > upgrade > > > > > many important dependencies. This includes Jetty and Spring so > every > > > > > release has dependencies shipped with lots of CVEs. > > > > > 2. We are unable to migrate to modern language features in JDK 17+ > > > > > (like switch statement) because 5.19.x supports JDK 11. > > > > > 3. It's a lot of extra work to keep having to backport and perform > > > > > releases for 5.x > > > > > 4. It's just time to move on and modernize. Jakarta has been around > > > > > since 2019 at this point. > > > > > > > > > > So we just need to pick a time frame and publish when we will stop > > > > > supporting it. I would prefer to keep the timeframe relatively > short, > > > > > maybe 6 months or something. > > > > > > > > > > While I would prefer to only support Jakarta, I know that clients > are > > > > > often the last to be upgraded and can take longer. So if it helps > > > > > migration we could easily add a project to generate a javax client > in > > > > > 6.x (essentially the opposite of what we did in 5.x). We can just > use > > > > > maven to repackage it. Also, if we do that we could change the > target > > > > > JDK to version 11 only for the client (we don't use any new > language > > > > > features anyways). This would at least allow people with older JDKs > > > > > and on javax to still get updates for the client only while we move > > > > > the broker forward. > > > > > > > > > > Chris > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > For further information, visit: > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > For further information, visit: https://activemq.apache.org/contact > > > > > > >
