Release with protobuf-java 4.x support (4.4 or 5.0)?

[alejandrohdezma]

Ask the question

Is a release of Tribuo built against protobuf-java 4.x planned, and if so, is there a rough timeline?

Tribuo 4.3.2, the latest release, depends on com.google.protobuf:protobuf-java:3.25.6
(via tribuo-core and tribuo-util-onnx, plus olcut-config-protobuf 5.3.1). The Google Cloud
client libraries, gRPC's managed BOMs, Confluent 8.x, ScalaPB 1.0 and most of the JVM ecosystem
have moved to protobuf-java 4.x. Any build that combines Tribuo with one of those ends up with a
3.x vs 4.x conflict on protobuf-java, which sbt and Gradle may flag as a binary-incompatible major
version change.

I saw that main already switched to protobuf-java 4.33.5 in #433 (February 2026), so the work
appears to be done and it is only a matter of publishing it. Would a 4.4.0 with that change be
possible, or is it being held for a 5.0?

Is your question about a specific ML algorithm or approach?

No.

Is your question about a specific Tribuo class?

None in particular. It concerns the protobuf-based serialization used across tribuo-core
(org.tribuo.protos.*) and tribuo-util-onnx.

System details

• Tribuo version: 4.3.2
• Java version: 17 and 25
• OS/Architecture: any (dependency resolution issue, not runtime)

Additional context

Runtime compatibility is not the problem. The 4.3.2 generated code targets GeneratedMessageV3,
which protobuf-java 4.x still ships, and the 4.x runtime explicitly tolerates generated
major version behind. The problem is purely at dependency resolution time: build tools refuse to
evict protobuf-java 3.25.6 to 4.x without a manual override, so every downstream project needs
a workaround for as long as Tribuo's published POM points at 3.x.

For context, we manage a shared BOM for Scala services and had to drop Tribuo from it because a
BOM pinning both protobuf-java 4.x and Tribuo 4.3.2 is internally inconsistent. Consumers now
pin Tribuo individually with a version-scheme override until a protobuf 4 release is available.

[Craigacp]

I think we'd consider that a breaking change, so it would be for 5.0. There isn't any plans for 4.4, there are several breaking changes we want to make (not least moving on from Java 8 to something more modern), and the main branch has landed a number of those already. Unfortunately I don't have a timeline on when 5.0 is likely to happen, our group was retasked last year and we have little time available for open source work at the moment. That may change in the future, but it's unclear.

Could your BOM pin Tribuo but exclude the protobuf dependency? We have a number of pins with exclusions already in the various Tribuo poms to work around dependency conflicts.

[alejandrohdezma]

Yes, I think that's the way we'll head until a new version is ready. Thank you very much for the fast response!