Hi JB-

Thanks for kicking off the convo, I think we are mostly in agreement.

We have more headroom with versions, so I think it would be good to be closer 
to SEMVER going forward.

6.0.x - Dependency updates (non-major changes). ActiveMQ bug and security fixes 
only. No new config flags (unless as part of a fix) or new features.

6.1.x - New features, new config flags, new JMS 2.x features, etc

I think 6.5.x is probably reasonable for full JMS 2.0 compliance. Chris started 
on the openwire modernization work, and I’ve got a couple tasks to kick-in over 
there as well.

Main changes for openwire — deliveryDelay field and shared subscription flag.

I have a PR for Virtual Thread support and plan on updating it to make it 
something that can be releasable without having to move everyone to JDK 21 in 
6.x. Getting some runtime testing with Virtual Threads in 6.x will be good and 
give data to consider it for the default in 7.x/8.x. 

Regarding 7.x — I think we can move more towards ‘services’ and 
DestinationPolicy add-ons vs ‘plugins'. I plan to start implementing more 
features under destination policy to replace more plugins (timestamp, forced 
persistence mode, etc). A config service that re-uses a lot from runtime config 
plugin would provide a lot of transition support towards an activemq-boot 
mini-kernel to replace Spring/XBean.

Thanks,
Matt Pavlovich

> On Jan 12, 2024, at 12:22 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi guys,
> 
> Happy new year to all !
> 
> After the festive break, I'm back on ActiveMQ :)
> I would like to discuss about the roadmap for ActiveMQ
> 6.0.x/6.1.x/6.2.x/7.x(future):
> 
> - For 6.0.x branch, I propose to include fixes and minor dependencies
> updates (I have some PRs on the way, Matt also worked on different
> topics)
> - For 6.1.x branch, I propose to add a new round of JMS 2.x/3.x
> features support and include major dependencies updates (if there are
> :)). It can also include non breaking change refactoring.
> - For 6.2.x branch, I propose to add another round of JMS 2.x/3.x
> features support and new major updates compared to 6.1.x
> It would be great to target 6.5.x for instance for full JMS 2.x/3.x support.
> 
> - For 7.x, I started a prototype to set Spring as optional, having a
> core loader and new configuration format (in addition to activemq.xml,
> I have activemq.json and activemq.yml for instance). As this is a
> major milestone, we could have some breaking changes. Even if 7.x is
> not the top priority for now (I think we have to focus on full JMS 2/3
> support right now), it gives perspective to the community.
> 
> Thoughts ?
> 
> Regards
> JB

Reply via email to