Yeah, agree with the plan, it looks good. I would suggest also to update the website when we will do the "end of active" announcement (I will try to resume the effort on the website too :)).
Regards JB On Sat, Aug 22, 2026 at 5:55 PM Matt Pavlovich <[email protected]> wrote: > > +1 Good call, I think that would cover the only realistic scenario we’d > want to go back and make sensible release of an inactive release stream. > > In summary: > > 1. Announce Feb 28th 2027 end of active for 5.19.x > 2. Leave ourselves an option to do for emergency (ie Log4shell, OpenWire > security vulnerability, etc) > > > > On Aug 22, 2026, at 10:41 AM, Christopher Shannon > > <[email protected]> wrote: > > > > 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 > > > > > > > --------------------------------------------------------------------- > 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
