Thanks Christopher, in hindsight, "removal" is a more appropriate term for what I was proposing and you were correct that deprecation should have its proper cycle.
That being said, I think the second option you proposed makes more sense to me. Just follow up on that, what is the proper deprecation cycle like in ActiveMQ Classic. From what you describe: 1. Mark the public API as "@Deprecated" when we release CompletionListener 2. In that release note, highlight that part. 3. Public documentation on migration strategy and recommendations 4. Jira ticket to remind ourselves that in ActiveMQ 7 we will remove that Do you have a past example that I can follow? Thanks, Ken On Mon, Nov 25, 2024 at 12:03 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > I forgot to say I think we should go through the second option I listed and > that is a proper deprecation and removal cycle to give users notice the old > API will go away the next major version. > > On Mon, Nov 25, 2024 at 3:01 PM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > I don't think the first two options are a good idea: > > > > 1) What you are calling deprecation is not actually deprecation as that > is > > a breaking change. Deprecated features are meant to mean no longer > > recommended and may go away but shouldn't just fail with an exception. > > Throwing an exception is worse than just deleting it entirely because now > > you don't get an error until runtime instead of compile time. > > 2) Changing the existing behavior is also not great because it changes > > what users are expecting at runtime without a good indication you are > doing > > so. Users are going to expect that something like that works a certain > way > > and you've just changed it. > > > > So based on that I think there are 2 options that make sense: > > > > 1) Option 3 that you listed - We could just keep them both with the > > different interfaces/behavior going forward. However, this only really > only > > makes sense to me if both interfaces are useful in different ways with > > different use cases but I'm not sure they are and could be confusing as > you > > pointed out. > > 2) We could temporarily support both and go through a proper deprecation > > cycle and removal. In this case we would mark AyncCallback as deprecated > > but still support it with the current behavior, and then for the next > major > > version (7.x) it would be removed entirely. When deprecating we can point > > users to the new API to use and explain the differences and recommend > they > > migrate. This would give users a notice that it is going away and time to > > switch over to CompletionListener before it's gone. That means in version > > 6.x we'd end up supporting both until it was removed. > > > > On Mon, Nov 25, 2024 at 1:26 PM Ken Liao <kenlia...@gmail.com> wrote: > > > >> Hey dev community, > >> > >> Would like to get your opinion on this. To make ActiveMQ Classic fully > >> support JMS 2.0/Jakarta Messaging 3.1, it needs to support > >> CompletionListener interface for specifying callback once the > asynchronous > >> send is completed. Currently, ActiveMQ Classic has its own public > >> interface > >> AsyncCallback for client applications to specify the callback. However, > >> the > >> behaviour of AsyncCallback is not JMS 2.0 compliant and it is specific > to > >> ActiveMQ. > >> > >> In my opinion, it will be a confusing experience for users because > there > >> are two mechanisms for specifying callbacks and I wonder if there are > any > >> advantages of using AsyncCallback over CompletionListener. Either: > >> 1. Deprecate AsyncCallback (throw exception) at the release where we > >> support CompletionListener. > >> 2. Change AsyncCallback behaviour to align with CompletionListener at > that > >> release. > >> 3. Keep supporting these two different interfaces/behavior going > forward. > >> > >> Personally I am advocating for 2 but would like to hear what the > community > >> thinks and check if I am missing something. > >> > >> Thanks, > >> Ken > >> > > >
