I see your point, I think we were talking different things and can cover both.
After the Jetty 12 work, I would prefer an activemq project-sourced branch to work from. Coordinating rebases and taking commits across private forked repos is a pain. How about a activemq-wip-jakarta-3.1 branch? That would allow us to also cover the other changes and hopefully get one OpenWire revision as well as TCK updates along the way. Thanks, Matt > On Jul 17, 2026, at 9:38 AM, Christopher Shannon > <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
