I'm honestly not really sure what "LTS" means in the context of ActiveMQ
since we have not adopted that specific label, but I believe it is being
equated here with the "Stable - Supported" designation from the Classic
download page [1] which includes 6.1.x, 5.19.x, & 5.18.x. To be clear, this
is the definition of "Stable - Supported" from the website [1]:
Actively supported and recommended for production use. This version
receives regular updates, including new features, security patches, and bug
fixes.
It seems such "regular updates" would overlap with your proposal, but these
series are not specifically included?
Justin
[1] https://activemq.apache.org/components/classic/download/
On Wed, Nov 12, 2025 at 2:24 PM Jean-Baptiste Onofré <[email protected]>
wrote:
> LTS doesn't necessarily mean all active branches (I'm not a big fan of
> LTS for Apache projects, as anyone can propose a new release on "old"
> branches). However I'm fine to do it on all active branches as soon as
> we have something to include in a release.
>
> Regards
> JB
>
> On Wed, Nov 12, 2025 at 9:01 PM Justin Bertram <[email protected]>
> wrote:
> >
> > > So, the "best effort monthly" cadence is only for the latest active
> branch.
> >
> > I think there's some confusion on this point given Matt's earlier
> comment about having "once-per-month release for dependency updates at a
> minimum for active LTS release steams."
> >
> >
> > Justin
> >
> > On Wed, Nov 12, 2025 at 1:50 PM Jean-Baptiste Onofré <[email protected]>
> wrote:
> >>
> >> Hi Justin,
> >>
> >> So, the "best effort monthly" cadence is only for the latest active
> >> branch. The other branches will stay "on demand".
> >>
> >> Regards
> >> JB
> >>
> >> On Wed, Nov 12, 2025 at 6:00 PM Justin Bertram <[email protected]>
> wrote:
> >> >
> >> > To further clarify...
> >> >
> >> > The website indicates that there are currently 3 "Stable - Supported"
> series - 6.1.x, 5.19.x, and 5.18.x. There is also 6.2.x which is "In Dev."
> Would this new policy result in potentially 4 total releases per month?
> >> >
> >> >
> >> > Justin
> >> >
> >> > On Wed, Nov 12, 2025 at 10:42 AM Jean-Baptiste Onofré <
> [email protected]> wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> I had a chat with Art, and he made me realize that this thread is not
> >> >> super clear, both in terms of "why" and "how".
> >> >>
> >> >> So, to summarize the why, the intentions for a "best effort monthly
> >> >> release cadence" are:
> >> >> 1. "More predictable" releases cycle for our users, with a high level
> >> >> expected release content.
> >> >> 2. Faster features/fixes shipping for our contributors (and us ;) ).
> >> >> At a high level, the goal is to even more grow our community (users
> >> >> and contributors).
> >> >>
> >> >> I'm volunteering to start doing "best effort monthly" releases unless
> >> >> there is any concern (starting in January).
> >> >>
> >> >> Regards
> >> >> JB
> >> >>
> >> >>
> >> >> On Wed, Nov 12, 2025 at 5:41 AM Jean-Baptiste Onofré <
> [email protected]> wrote:
> >> >> >
> >> >> > Hi
> >> >> >
> >> >> > It's up to the projects to decide their release frequency (so no
> >> >> > guideline or rule at foundation level).
> >> >> >
> >> >> > My proposal (and the purpose) is to have a predictable release
> cycle
> >> >> > for the users and ship fixes/updates faster.
> >> >> >
> >> >> > Regards
> >> >> > JB
> >> >> >
> >> >> > On Tue, Nov 11, 2025 at 9:36 PM Arthur Naseef <[email protected]>
> wrote:
> >> >> > >
> >> >> > > Are there guidelines or rules around release frequency? If so,
> I'm not
> >> >> > > aware - even when I did some releases.
> >> >> > >
> >> >> > > Are there any real concerns we want to address here?
> >> >> > >
> >> >> > > Art
> >> >> > >
> >> >> > >
> >> >> > > On Tue, Nov 11, 2025 at 1:07 PM Matt Pavlovich <
> [email protected]> wrote:
> >> >> > >
> >> >> > > > +1 on this approach. I think it may be clarified like this:
> >> >> > > >
> >> >> > > > “Best effort” once-per-month release for dependency updates at
> a minimum
> >> >> > > > for active LTS release steams.
> >> >> > > >
> >> >> > > > Example: v6.2.1 & v5.19.7, then v6.2.2, v5.19.8, etc.
> >> >> > > >
> >> >> > > > Then minor and major releases as needed or in the monthly
> release window
> >> >> > > > as it works out.
> >> >> > > >
> >> >> > > > -Matt
> >> >> > > >
> >> >> > > > > On Nov 11, 2025, at 11:24 AM, Christopher Shannon <
> >> >> > > > [email protected]> wrote:
> >> >> > > > >
> >> >> > > > > Best effort is fine with me in that case. As long as it's
> not super
> >> >> > > > > "strict", monthly works if we have stuff ready to go.
> >> >> > > > >
> >> >> > > > > Dependabot would be nice, it would make the updates easier
> to have it
> >> >> > > > more
> >> >> > > > > automated if possible.
> >> >> > > > >
> >> >> > > > > On Tue, Nov 11, 2025 at 11:55 AM Jean-Baptiste Onofré <
> [email protected]>
> >> >> > > > > wrote:
> >> >> > > > >
> >> >> > > > >> Also, something I'm proposing is to join the ATR initiative.
> >> >> > > > >>
> >> >> > > > >> Regards
> >> >> > > > >> JB
> >> >> > > > >>
> >> >> > > > >> On Tue, Nov 11, 2025 at 5:53 PM Jean-Baptiste Onofré <
> [email protected]>
> >> >> > > > >> wrote:
> >> >> > > > >>>
> >> >> > > > >>> Hi Chris,
> >> >> > > > >>>
> >> >> > > > >>> Sorry I was not clear in my previous message: the intent
> is not to
> >> >> > > > >>> have something strict but more as "best effort". If we
> don't have any
> >> >> > > > >>> change, no need to release. But as soon as we have
> something, we can
> >> >> > > > >>> ship asap.
> >> >> > > > >>> So, I think we are on the same page ;)
> >> >> > > > >>>
> >> >> > > > >>> About the dependency updates, I was thinking about
> >> >> > > > >>> dependabot/renovatebot, but it's a separate discussion I
> will start :)
> >> >> > > > >>>
> >> >> > > > >>> Regards
> >> >> > > > >>> JB
> >> >> > > > >>>
> >> >> > > > >>> On Tue, Nov 11, 2025 at 5:37 PM Christopher Shannon
> >> >> > > > >>> <[email protected]> wrote:
> >> >> > > > >>>>
> >> >> > > > >>>> Hi Jb,
> >> >> > > > >>>>
> >> >> > > > >>>> In general, releasing more frequently is definitely good,
> and I'm not
> >> >> > > > >>>> against releasing monthly if there is stuff to release,
> but I'm not
> >> >> > > > >> really
> >> >> > > > >>>> in favor of having any kind of super fixed release
> schedule because a
> >> >> > > > >> lot
> >> >> > > > >>>> of issues come up from it and being flexible is important
> so i think
> >> >> > > > we
> >> >> > > > >>>> might want to be a little be less rigid.
> >> >> > > > >>>>
> >> >> > > > >>>> 1. A guaranteed monthly release means something could
> go out that
> >> >> > > > >> has
> >> >> > > > >>>> very little changes. With ActiveMQ not a ton of changes
> happen
> >> >> > > > >> every month
> >> >> > > > >>>> so many times there's not much to release and simple
> dependency
> >> >> > > > >> updates and
> >> >> > > > >>>> minor fixes can be done in minor releases instead.
> >> >> > > > >>>> 2. You can get into the opposite situation where stuff
> is ready to
> >> >> > > > >> be
> >> >> > > > >>>> released but we are stuck waiting for the release time.
> (this is
> >> >> > > > >> not really
> >> >> > > > >>>> a big deal for a month long cadence but for longer it
> is)
> >> >> > > > >>>> 3. Usually this causes more problems because dates get
> missed. This
> >> >> > > > >> is
> >> >> > > > >>>> all volunteer work after all, so I've seen a lot of
> situations
> >> >> > > > >> where the
> >> >> > > > >>>> promised releases never go out on time. For Kafka for
> example, they
> >> >> > > > >> have a
> >> >> > > > >>>> release schedule and it is almost never on time. The
> releases
> >> >> > > > >> always go out
> >> >> > > > >>>> later because of any number of delays.
> >> >> > > > >>>>
> >> >> > > > >>>> I think we can certainly encourage faster releases but
> maybe be a bit
> >> >> > > > >> more
> >> >> > > > >>>> flexible, something like:
> >> >> > > > >>>>
> >> >> > > > >>>> - We can try and release monthly if there are things
> ready to go
> >> >> > > > >> out,
> >> >> > > > >>>> but can be flexible and skip a month or 2 (nothing
> important to
> >> >> > > > >> release,
> >> >> > > > >>>> other issues come up,etc).
> >> >> > > > >>>> - We can plan to release a major version at least once
> a quarter
> >> >> > > > >> (ie.
> >> >> > > > >>>> 6.3.0 or 6.4.0) if we skipped months
> >> >> > > > >>>> - If we don't release a major update for that month we
> can always at
> >> >> > > > >>>> least do a minor update ie 6.3.1
> >> >> > > > >>>> - Release faster if something important is needed (this
> is probably
> >> >> > > > >>>> unlikely) is fine too
> >> >> > > > >>>>
> >> >> > > > >>>> Chris
> >> >> > > > >>>>
> >> >> > > > >>>> On Tue, Nov 11, 2025 at 11:08 AM Jean-Baptiste Onofré <
> >> >> > > > [email protected]
> >> >> > > > >>>
> >> >> > > > >>>> wrote:
> >> >> > > > >>>>
> >> >> > > > >>>>> Hi folks,
> >> >> > > > >>>>>
> >> >> > > > >>>>> In order to ship changes faster (I'm thinking of the
> discussion about
> >> >> > > > >>>>> VirtualThread in Classic 6.2.0 for instance), and to
> have a
> >> >> > > > >>>>> "predictable" cycle for our users, I would like to
> propose a monthly
> >> >> > > > >>>>> release pace for ActiveMQ Classic.
> >> >> > > > >>>>>
> >> >> > > > >>>>> For instance, it means that 6.3.0 can be released in
> December, 6.4.0
> >> >> > > > >>>>> in January, etc.
> >> >> > > > >>>>>
> >> >> > > > >>>>> The purpose is also to encourage contributors as their
> contributions
> >> >> > > > >>>>> will be included in releases faster.
> >> >> > > > >>>>> I also think that it would be a good way to be up to
> date with
> >> >> > > > >>>>> dependencies (I'm thinking of the discussion about a
> bunch of Jira
> >> >> > > > >>>>> regarding dependency updates in Classic 6.2.0).
> >> >> > > > >>>>>
> >> >> > > > >>>>> Thoughts?
> >> >> > > > >>>>>
> >> >> > > > >>>>> Regards
> >> >> > > > >>>>> JB
> >> >> > > > >>>>>
> >> >> > > > >>>>>
> ---------------------------------------------------------------------
> >> >> > > > >>>>> 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
> >> >>
> >> >>
> >>
>
>
