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
