You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Christopher Shannon <ch...@gmail.com> on 2026/08/06 20:35:14 UTC
Re: [DISCUSS] End of Life timeline for 5.x
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
<jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
>
> > I think the direction is reasonable. +1
> >
> > On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > Does anyone else have anymore thoughts on this?
> > >
> > > On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> > > <ch...@gmail.com> 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é <jb@nanthrax.net
> > >
> > > 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 <
> > > > > christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> > > > > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > > > > For further information, visit:
> > https://activemq.apache.org/contact
> > > > > >
> > > > > >
> > > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Christopher Shannon <ch...@gmail.com>.
Ok sounds JB, I agree we can send out an email announcement and update
the website for 5.19.x for users as well.
On Mon, Aug 24, 2026 at 9:14 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> 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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> > > <ch...@gmail.com> 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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> > >>>> <ch...@gmail.com> 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
> > >>>>> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
> > >>>>>>
> > >>>>>>> I think the direction is reasonable. +1
> > >>>>>>>
> > >>>>>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> > >>>>>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>>>>
> > >>>>>>>> Does anyone else have anymore thoughts on this?
> > >>>>>>>>
> > >>>>>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> > >>>>>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
> > >>>>>>>>
> > >>>>>>>> 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 <
> > >>>>>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> > >>>>>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> > >>>>>>>>>>> For further information, visit:
> > >>>>>>> https://activemq.apache.org/contact
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> > >>>>>>>> For further information, visit: https://activemq.apache.org/contact
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > >>>> For additional commands, e-mail: dev-help@activemq.apache.org
> > >>>> For further information, visit: https://activemq.apache.org/contact
> > >>>>
> > >>>>
> > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: dev-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> > <ch...@gmail.com> 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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> >>>> <ch...@gmail.com> 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
> >>>>> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
> >>>>>>
> >>>>>>> I think the direction is reasonable. +1
> >>>>>>>
> >>>>>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> >>>>>>> christopher.l.shannon@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Does anyone else have anymore thoughts on this?
> >>>>>>>>
> >>>>>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> >>>>>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
> >>>>>>>>
> >>>>>>>> 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 <
> >>>>>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> >>>>>>>>>>> For further information, visit:
> >>>>>>> https://activemq.apache.org/contact
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> >>>>>>>> For further information, visit: https://activemq.apache.org/contact
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> >>>> For additional commands, e-mail: dev-help@activemq.apache.org
> >>>> For further information, visit: https://activemq.apache.org/contact
> >>>>
> >>>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: dev-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Matt Pavlovich <ma...@apache.org>.
+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 <ch...@gmail.com> 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
> <ch...@gmail.com> 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 <ma...@apache.org> 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 <ch...@gmail.com> 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
>>>> <ch...@gmail.com> 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
>>>>> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
>>>>>>
>>>>>>> I think the direction is reasonable. +1
>>>>>>>
>>>>>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
>>>>>>> christopher.l.shannon@gmail.com> wrote:
>>>>>>>
>>>>>>>> Does anyone else have anymore thoughts on this?
>>>>>>>>
>>>>>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
>>>>>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
>>>>>>>>
>>>>>>>> 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 <
>>>>>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
>>>>>>>>>>> For further information, visit:
>>>>>>> https://activemq.apache.org/contact
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
>>>>>>>> For further information, visit: https://activemq.apache.org/contact
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
>>>> For additional commands, e-mail: dev-help@activemq.apache.org
>>>> For further information, visit: https://activemq.apache.org/contact
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Christopher Shannon <ch...@gmail.com>.
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
<ch...@gmail.com> 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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> > > <ch...@gmail.com> 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
> > >> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
> > >>>
> > >>>> I think the direction is reasonable. +1
> > >>>>
> > >>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> > >>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>
> > >>>>> Does anyone else have anymore thoughts on this?
> > >>>>>
> > >>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> > >>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
> > >>>>>
> > >>>>> 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 <
> > >>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> > >>>>>>>> For further information, visit:
> > >>>> https://activemq.apache.org/contact
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > >>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> > >>>>> For further information, visit: https://activemq.apache.org/contact
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Christopher Shannon <ch...@gmail.com>.
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 <ma...@apache.org> 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 <ch...@gmail.com> 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
> > <ch...@gmail.com> 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
> >> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
> >>>
> >>>> I think the direction is reasonable. +1
> >>>>
> >>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> >>>> christopher.l.shannon@gmail.com> wrote:
> >>>>
> >>>>> Does anyone else have anymore thoughts on this?
> >>>>>
> >>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> >>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
> >>>>>
> >>>>> 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 <
> >>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> >>>>>>>> For further information, visit:
> >>>> https://activemq.apache.org/contact
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> >>>>> For additional commands, e-mail: dev-help@activemq.apache.org
> >>>>> For further information, visit: https://activemq.apache.org/contact
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: dev-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Matt Pavlovich <ma...@apache.org>.
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 <ch...@gmail.com> 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
> <ch...@gmail.com> 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
>> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
>>>
>>>> I think the direction is reasonable. +1
>>>>
>>>> On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
>>>> christopher.l.shannon@gmail.com> wrote:
>>>>
>>>>> Does anyone else have anymore thoughts on this?
>>>>>
>>>>> On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
>>>>> <ch...@gmail.com> 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é <jb@nanthrax.net
>>>>>
>>>>> 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 <
>>>>>>> christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
>>>>>>>> For further information, visit:
>>>> https://activemq.apache.org/contact
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
>>>>> For additional commands, e-mail: dev-help@activemq.apache.org
>>>>> For further information, visit: https://activemq.apache.org/contact
>>>>>
>>>>>
>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
Re: [DISCUSS] End of Life timeline for 5.x
Posted by Christopher Shannon <ch...@gmail.com>.
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
<ch...@gmail.com> 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
> <jl...@tomitribe.com> 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. <ja...@gmail.com> wrote:
> >
> > > I think the direction is reasonable. +1
> > >
> > > On Fri, Jul 17, 2026 at 10:37 Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > > > Does anyone else have anymore thoughts on this?
> > > >
> > > > On Fri, Jul 10, 2026 at 8:29 AM Christopher Shannon
> > > > <ch...@gmail.com> 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é <jb@nanthrax.net
> > > >
> > > > 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 <
> > > > > > christopher.l.shannon@gmail.com> 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: dev-unsubscribe@activemq.apache.org
> > > > > > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > > > > > For further information, visit:
> > > https://activemq.apache.org/contact
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: dev-help@activemq.apache.org
> > > > For further information, visit: https://activemq.apache.org/contact
> > > >
> > > >
> > > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact