As far as I can tell, the fact that one would need to change what one was doing previously to get the same behavior technically makes this a "breaking change." We really don't know how folks are using the "create" command and how that relates to their migration or upgrade processes. Also, the fact that there is a flag to disable it means that folks who really care are almost certainly disabling it already.
We have a policy of no breaking changes in minor releases. I think we should stick to it regardless of how unlikely it may be that folks are using the functionality in question. I think it's good practice and helps give our users confidence in the upgrade process which is important because we want them to upgrade since it makes our jobs easier. Justin On Wed, Aug 7, 2024 at 9:11 AM Clebert Suconic <clebert.suco...@gmail.com> wrote: > it's not a breaking change.. they can always do : > > ./artemis create --enable-hornetq-adapter... > > that will only affect new servers... new configurations created from > now on will not have hornetQ. if you migrate a previous configuration > with upgrade, it will still be there. > > > it's been 37 versions since HornetQ (even more if you count the . > release and the 1.0 releases)... I doubt anyone would be using it at > this point. Keep adding the acceptor for HornetQ at this point it's a > waste of resources for everybody. > > On Wed, Aug 7, 2024 at 9:52 AM Justin Bertram <jbert...@apache.org> wrote: > > > > Generally speaking I agree, but I'm not sure we can make that change in a > > minor release since it changed the default behavior and it's not > > technically a bug. Maybe wait until 3.0? > > > > > > Justin > > > > On Tue, Aug 6, 2024 at 11:01 PM Clebert Suconic < > clebert.suco...@gmail.com> > > wrote: > > > > > I just realized we still create the following acceptor on every server > we > > > start: > > > > > > > > > <!-- HornetQ Compatibility Acceptor. Enables HornetQ Core > > > and STOMP for legacy HornetQ clients. --> > > > > > > <acceptor > > > name="hornetq">tcp:// > > > > 0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true > > > </accept > > > > > > > > > > > > > > > And I think we should stop. 61616 would still respond to HornetQ > > > protocol. It just don't make sense (for a few. years already .. don't > > > know how we missed) to keep this acceptor. > > > > > > > > > I think we should switch the defaults on the CLI create to have it off > > > by default, and add a new parameter as --enable-hornetq-acceptor. > > > > > > -- > > > Clebert Suconic > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > For further information, visit: https://activemq.apache.org/contact > > > > > > > > > > > > > -- > Clebert Suconic > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
