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 >> >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
