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