Hi Chris- Thanks for kicking of this thread. A quick primer on what was pushed—
I implemented two extended classes (SharedTopicBrokerService, SharedTopicConnectionFactory) and marked them with the @Experimental annotation. This keeps the code flow out of any current classes. The intention is to allow developers to test the features independently, and not introduce potentially breaking changes to the main tree. In theory, we could release it in this form this and get a round of feedback from end users. (Possibly also add @Deprecated to those classes). To test, fire up a SharedTopicBrokerService and connect using SharedTopicConnectionFactory. I have a run of the TCK going against this change set to cross check functionality against the TCK and will report back on the PR. Also, I’ll start working to make the commit that would merge the SharedTopicFoo classes into their final targets. As far as a feature branch goes, I’m not opposed to it; however, I’m not sure how to break up the work to where releases could happen and partial pieces merged. I don’t figure we’d want to ship OpenWire v13 without some implementation, and if that’s the case, don't you kind of need everything? Perhaps that’s a good starting point of the discussion?Review the PR and suggest how different pieces could be merged into releases without taking the whole thing? Thanks! Matt Pavlovich > On Jul 17, 2026, at 8:04 AM, Christopher Shannon > <[email protected]> wrote: > > Hi Everyone, > > I wanted to start a discussion for working on shared subscription > support after Matt pushed some initial work to > https://github.com/apache/activemq/pull/2225. I commented on that PR > with the same info but after that I realized it should really be here > as a dev discussion > > I think the best approach is to create a long running feature branch > (doesn't matter what it is called). Shared subscription support is > going to take a lot of work and needs to be done in several steps. By > isolating the work into a separate branch we can create lots of PRs to > split up the work without having to worry about breaking the build > which is going to happen. There's a lot of changes so it might take a > few iterations until we are happy with it. With a separate branch we > can also avoid having to worry about keeping existing things working > with transition or temporary classes to isolate things. > > After creating the branch we need to periodically merge the main > branch into it (note I said merge, we don't want to rebase) to keep > things up to date. Once we think it's good we can create a PR and > merge the feature branch back into main and preserve the commit > history. > > So the basic flow would be: > > 1. Create a feature branch for shared sub support in the activemq repo > 2. periodically merge main into it to keep it up to date and resolve conflicts > 3. create PRs against the feature branch > 4. Merge the feature branch back into main when we are done > > Chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
