Hi, I agree that using feature branches is a very effective approach for many Apache projects. It is incredibly helpful when we need to group significant changes and collaborate on them before merging into the main branch, ensuring main remains stable and clean.
We can create these feature branches directly on the apache/activemq repository, allowing committers to push to them directly. Once we reach a consensus and the work is in an agreed state, we can open a PR against main. To keep everything up to date, the feature branch should be regularly synced with main. For example, we used this exact approach in Apache Polaris when updating to Apache Iceberg 1.11, which allowed us to successfully collaborate on the new design and breaking changes. To clarify, this makes the most sense for large, significant changes. "Regular" everyday changes should continue to be pushed directly to the repository as we normally do. Ultimately, I strongly prefer a shared "feature branch" over private forks/branches for a few key reasons: 1. It encourages collaboration and helps build consensus. 2. It provides clear visibility to contributors who might want to help. 3. It allows us to discuss design publically within the branch. In my opinion, relying on private forks or private branches hinders collaboration in our projects (the "lonesome cowboy" syndrom :)). Regards, JB On Fri, Jul 17, 2026 at 5:53 PM Christopher Shannon <[email protected]> wrote: > > Something like that works. Also, we don't need to leave the branch > open forever, if we think something is pretty close and ready for > "beta" we could move it into the main branch. > > We can also create other feature branches for other stuff if needed > but we probably don't need to, I think that this is pretty unique to > the jakarta shared sub changes just because of the scope of them. > > On Fri, Jul 17, 2026 at 11:02 AM Matt Pavlovich <[email protected]> wrote: > > > > 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 > > > > > > --------------------------------------------------------------------- > 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
