Everything seems fine as a general guideline but I wouldn't guarantee "full compliance" on any specific 6.x release as it's just hard to say when it will happen. It's a goal that is being worked on each release and there's still a good amount of work to do so hopefully we get there but it's hard to say if it will be 6.5 or 6.6 etc. Certainly if/when a 7.0 release happens I would expect that to be fully Jakarta compliant with the spec.
On Thu, Feb 29, 2024 at 2:02 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Matt > > Yeah, agree. It sounds good. > > I'm on the releases right now. Votes will come soon :) > > Regards > JB > > On Tue, Feb 27, 2024 at 8:16 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > > > 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 > > >
