Ken, Those steps sound generally correct to me on what I would do. It's a bit more work on our end to have to maintain the legacy interface for a while but it's a lot nicer from the user standpoint.
In terms of previous examples, I would have to go back and look. Off the top of my head I don't know that we really have many examples which actually brings up an annoying issue with AMQ... not many things have been deprecated and cleaned up over the years so there is a lot of bloat in the code. A big reason for this is we were stuck on 5.x for such a long time that there wasn't really a chance to make big breaking changes to the API without a major version bump. Now that major versions can be bumped I'd actually like to go back and look at other things to deprecate and mark for removal in version 7.0 as there's probably plenty of other things we can clean up. It would also be a good time to make any changes to default configs as well. Many times we have added features and just left the old behavior intact to not change behavior for existing users even if the new feature is a better way of doing it, so it might be time to review the different settings for the next major version. Chris On Mon, Nov 25, 2024 at 6:48 PM Ken Liao <kenlia...@gmail.com> wrote: > 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 > > >> > > > > > >
