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
