+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
