I agree the code and API will not change frequently. However, when it does change it will be more complicated working out of two trees vs having one tree to merge a PR — specifically shared subscriptions and other modernization ideas — like tracking destination deletes, purges, etc. and the proposed work on replication. It would require patches/release/alignment or working with SNAPSHOTs when in two repos.
I think the work to keep the modernized and secured — maven plugins, JDK version alignment, code style, etc.. is all easier as part of the main tree vs having a separate repo and release cycle. Version alignment and compatibility becomes harder for users to understand intuitively and for us to maintain: activemq-broker-7.0.0 / activemq-protobuf-2.0 activemq-broker-6.3.0 / activemq-protobuf-1.1 There are virtually no consumers referencing the jar itself via maven — and the two most prominent ones would pickup the versions naturally by the protobuf jar version jumping to match the distro. Flipping the question around— why keep it separate? It is another JIRA/repo/issues/PRs etc to track and maintain vs hosting the classes and being able to make changes going forward as one-PR to one repo. Matt > On Mar 26, 2026, at 2:43 PM, Christopher Shannon > <[email protected]> wrote: > > It has been a long time since this came up but it looks like I already made > the point on the PR that the protobuf code almost never changes. The last > release was done in 2010 so it hasn't been updated in 16 years. > > So my main question is what exactly are you expecting to change that we > would need to be releasing every version or prototyping? > > I certainly expect that we might need to make some changes soon if we are > making updates for shared subscriptions or if we want to modernize it, but > I would think we'd update the version once and then it probably wouldn't > change for another 16 years. > > I'm not necessarily against it per se but I'm just struggling to see why we > need to do this and what you expect will be changing frequently enough to > justify the move vs keeping it separate and only releasing it when > infrequent updates happen. > > Chris > > > > > > On Tue, Mar 24, 2026 at 10:21 AM Matt Pavlovich <[email protected]> wrote: > >> The activemq-protobuf project was split out from the main line project a >> while ago and I don’t think it serves the project having it split out. >> >> 1. It is more work to maintain an independent module that is rarely used >> by any other project (JDK alignment, Maven modules, release, vote, issues, >> etc) >> see: >> https://mvnrepository.com/artifact/org.apache.activemq.protobuf/activemq-protobuf/1.1 >> >> Note: The next release would automatically signal an upgrade to any >> consumer of this jar by the version number being higher than the current >> >> 2. Having this hosted will allow us to more quickly experiment and modify >> the broker for any datastore changes that need to be made— changes to >> activemq-protobuf and other activemq-* modules may need to be merged >> together for feature changes vs ‘guessing’ if a design works in >> activemq-protobuf, releasing and then changing the main broker modules. >> >> PR discussion here: >> https://github.com/apache/activemq/pull/1209 >> >> Thanks, >> Matt Pavlovich --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
