Also, if we do announce the 6 month thing, we could still leave open the option for "emergency" releases. We have done that in the past, I just wouldn't want to promise anything or have anyone count on more fixes.
Chris On Sat, Aug 22, 2026 at 10:21 AM Christopher Shannon <[email protected]> wrote: > > I am ok with 4-6 months but am -1 on doing something longer and I plan > to -1 any releases after that. > > At the end of the day, it doesn't matter how much time we give because > whatever the timeline is, some people will just wait until the last > second to do the work to upgrade so we need to cut it off. > > JDK 17 has been out for 5 years and Jakarta has been out for longer, > It's more than past time to move on. > > On Fri, Aug 21, 2026 at 3:03 PM Matt Pavlovich <[email protected]> wrote: > > > > I agree it is a good time to announce a planned end of ‘active’ status to > > 5.19.x > > > > As you mentioned, this opens up the ability to start using JDK 17 features > > and beyond. > > (Virtual Threads and the JAAS change is really going to drive us to a JDK > > 25 baseline runtime anyway) > > > > As far as timeframe, end of year would put it at 4mos. Going up to 6 mos > > may be something to consider (ie Feb 28 2027). > > > > In this thread (or another), JB mentioned perhaps doing a longer 5.19.x > > active status since this will be the last of the javax.jms supported client > > to balance not releasing a javax.jms client in the 6.x tree. Per the Azul > > report ~ 38% of enterprises still running JDK 8 and 11 (ref: > > https://keyholesoftware.com/java-trends-2026/) > > > > Thanks, > > Matt > > > > > On Aug 21, 2026, at 7:31 AM, Christopher Shannon > > > <[email protected]> wrote: > > > > > > It sounds like everyone is on the same page to say that 5.19.x is not > > > active anymore going forward, so I think we can go ahead and announce > > > that and update the website, etc. This also means it should be safe to > > > start using JDK 17 features finally, like updated switch statements or > > > intanceof pattern matching as we won't be backporting. > > > > > > Because our web site still says that 5.19.x is stable and we haven't > > > actually announced that 5.19.x will stop being supported, I think it > > > makes sense to provide a short period of time for important/security > > > updates still. > > > > > > I'm proposing until the end of the year for 5.19.x. I think we could > > > announce that we will provide patch releases for 5.19.x that include > > > major bug fixes (should be rare or non-existent) and security fixes > > > (including dependency updates) until Dec 31st, 2026 and then we will > > > cut it off. This shouldn't be a lot of work as we'd only be > > > backporting limited stuff and I wouldn't expect many releases but that > > > also just depends on security reports. > > > > > > Ultimately, we just have to cut it off at some point because if you > > > don't give a deadline then some people just won't ever upgrade. > > > > > > Chris > > > > > > On Thu, Aug 6, 2026 at 4:35 PM Christopher Shannon > > > <[email protected]> wrote: > > >> > > >> 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 > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
