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
