+1 on the proposal. A predictable release cadence can manage expectations from contributors and encourage more contributions in my opinion. Of course, we need to be pragmatic and make sure those releases make sense. That said, I think the existing voting mechanism serves as a guardrail. Cutting a release, drafting the release note and testing the release can be further automated given the latest advancement of AI. So I am very much looking forward to this proposal. Thanks for putting it together JB!
Thanks, Ken On Wed, Nov 12, 2025 at 3:06 PM Jean-Louis Monteiro < [email protected]> wrote: > Hi JB and all, > > Thanks for putting this together. > I agree that visibility counts. And I also agree we need to be pragmatic. > Releasing because we have to release even if there is nothing does not make > sense. It will just put more pressure on people already carrying the load. > > But overall very pleased to hear that, especially if there are plans to > make some "big" improvements. > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Wed, Nov 12, 2025 at 11:59 PM Justin Bertram <[email protected]> > wrote: > > > 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 > > > >> >> > > > >> >> > > > >> > > > > > > > > >
