I think it's a total waste of resources to keep adding hornetq after 9 years since Artemis 1.0.0 release. We are making *everybody* to have a default hornetq acceptor for the hypothetical one user that is still using it and keeps upgrading every release we make. So, that's a total inexistent case...
You're concerned about an automated script to create the release for a hornetq older client.. if such user was that careful on automating the upgrade from hornetq every time, why he just didn't upgrade everything.. I think it's a total waste and non issue... I think it should be off by default. On Wed, Aug 7, 2024 at 11:05 AM Justin Bertram <jbert...@apache.org> wrote: > > It seems pretty black & white to me. Forcing application clients to change > their code or configuration for an upgrade is the definition of a breaking > change. Forcing admins to change their commands or scripts to get the same > configuration as before is also a breaking change. Am I missing something? > > The behavioral (and sometimes breaking) changes enumerated in versions.adoc > for each release are about unavoidable changes resulting from fixing bugs > or minor changes from adding new features. Those cases seem categorically > different from this one. > > > Justin > > On Wed, Aug 7, 2024 at 9:48 AM Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > @Justin Bertram I will agree to disagree with you on that one :) > > > > If we stick with that policy, we wouldn't be able to do anything.. we > > have the versions.adoc for that particular reason... and we always > > have specific instructions in there. > > > > > > the 61616 acceptor will still accept hornetQ connections, you just > > need to configure the host and port from clients..so anyone still > > using hornetq clients can still connect to artemis with a slight URI > > modification. > > > > On Wed, Aug 7, 2024 at 10:45 AM Justin Bertram <jbert...@apache.org> > > wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > -- > > Clebert Suconic > > > > -- 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
