Yeah, you are right: it's better to not take any commitment for a specific version.
Let's do our best to add the missing parts, and we will do the releases on the fly. Regards JB On Thu, Feb 29, 2024 at 1:31 PM Christopher Shannon <christopher.l.shan...@gmail.com> wrote: > > 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 > > > > >
