Hi Chris-
My comments in-line below. For the most part, I agree in full. Any of the work
that we can break up into minor or patch releases would be good from the
standpoint of getting some runtime of all the changes under our belt before
rolling out the major breaking change parts.
> On Dec
+1 on openwire generator code project modernization
> On Dec 4, 2023, at 6:19 AM, Christopher Shannon
> wrote:
>
> Speaking of protocol changes, if we do generate a new openwire version to
> add shared sub commands we have to actually fix the Openwire generator
> including the CVE issue.
>
>
Yup agree and it means a new major version imho.
Le lun. 4 déc. 2023 à 13:19, Christopher Shannon <
christopher.l.shan...@gmail.com> a écrit :
> Speaking of protocol changes, if we do generate a new openwire version to
> add shared sub commands we have to actually fix the Openwire generator
>
We can have a roadmap and targets for things but the main thing I'm pushing
back on is having firm dates as there is a lot of unknown. There is a lot
of work left to do and it will take time to get things correct. We don't
want to have a rushed/bad implementation that is buggy.
For one thing, if
Ok. But in that case, can we target SMX 7 with full JMS 2 support ?
I think it’s important to have a kind of roadmap.
So let’s use 6.x for incremental work and 7 when complete (without strong
commitment on date).
Regards
JB
Le lun. 4 déc. 2023 à 13:18, Christopher Shannon <
Speaking of protocol changes, if we do generate a new openwire version to
add shared sub commands we have to actually fix the Openwire generator
including the CVE issue.
On Mon, Dec 4, 2023 at 7:18 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> I don't see how we can release
I don't see how we can release shared subscription support for 6.1.0 at
this point. We haven't even come up with a plan of how we are going to
implement it. There's multiple ways it could be done and probably requires
protocol changes. We have to decide how much work is done by the broker and
