Matt, You said "I'm not sure how to break up the work to where releases could happen and partial pieces merged" but I think you might be missing my point.
The point is I don't think we should merge any partial pieces, we merge it when it's done. Shared subscription support is one big feature, there's no need to merge in partial work People can test things in the feature branch. A feature branch allows us to push in partial work as we work on it, without breaking the main build. This change is very unique compared to other work we have done because of the scope. There is a high change of multiple iterations and having to go back and rework things. We might throw things away or do significant refactoring or decide there's a better way to do it and this is very much in the prototype phase. Or we might not...but having it isolated gives us freedom. With your example of Openwire v13, we are free to merge it into that branch because it won't go into the main build yet. There's no need and this lets us keep tweaking it. If we merge in v13 too early we might decide we did it wrong and need a v14. We don't need to merge stuff into main and release it to experiment, people can experiment from the branch and if we really wanted we could release RCs or something like that. Chris On Fri, Jul 17, 2026 at 9:35 AM Matt Pavlovich <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
