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
> >
> >
>

Reply via email to