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
