So now that 6.3.x is out are we good to stop supporting 5.19.x? I personally have no desire to release anymore versions and think we can cut it off.
Also, I think 6.2.9 will be the last of the 6.2.x series, users can move to 6.3.x going forward. On Sat, Jul 18, 2026 at 7:57 AM Jean-Louis Monteiro <[email protected]> wrote: > > 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 > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
