That makes sense to me, bugfixes in the 6.0.x patch version and extended functionality (JMS 2 and perhaps better observability) in 6.1.
I suggest code base modernization might be saved for within the 6.1 series but not 6.1.0, so we are not mixing new functionality with under the hood refactoring too much, as that could make it more difficult to understand the root cause for any regressions. Bruce On Sat, Dec 2, 2023, 9:01 p.m. Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi > > I think it's really important to focus on JMS 2 complete impl for 6.1.0. > That's the most important. > > I started to work on some impl, a couple are a little longer to impl, > require tests etc. > I don't think early January is reasonable. I would rather try at the > end of January. > > I would rather: > 1. Focus on 6.0.2 for fixes (I'm preparing 5.18.x/5.17.x too as they > include fixes as well) > 2. Focus on 6.1.0 to complete JMS 2.x support. That's probably the > most important (honestly, I'm not a big fan of JMS 2.x support in > ActiveMQ 6.0.x, it could be confusing for users). > > Regards > JB > > On Sat, Dec 2, 2023 at 4:10 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > > > All- > > > > I’ve started organizing some JIRAs for v6.1.0. I’m thinking > early-January for release target timeframe. > > > > - Additional JMS 2.0 impls > > - New features for observability > > - Code base modernization > > > > Thanks! > > Matt Pavlovich > > > > >