# Apache Dubbo is a registry-coupled RPC framework, and its version table has two wrong links > Apache Dubbo is a Java RPC and microservice framework that pairs wire protocols (Triple, Dubbo2, REST) with registry-based discovery and traffic strategies, and it is also the front door to six sibling implementations in other languages. The protocol story is settled. The version table in the README is not. **apache/dubbo** — The java implementation of Apache Dubbo. An RPC and microservice framework. - Repository: https://github.com/apache/dubbo - Website: https://dubbo.apache.org/ - Stars: 41,582 · Forks: 26,357 - Language: Java - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/apache-dubbo ## A dependency and a YAML config, with the coordinate on the task page The quick start has two routes and neither one gives you a copy-and-paste coordinate. One is the lightweight RPC API, described as a minimal codebase and a lightweight SDK, with a five-minute guide linked from the README. The other is a Spring Boot Starter, where the claim is that a dependency and a YAML configuration are enough to get service discovery, observability, and tracing. The Maven coordinates for both live on the linked task pages, not in the README. That is an unusual amount of nothing for a project whose first user question is which artifact to add. If you are evaluating Dubbo, budget a trip to the documentation site before you budget a prototype. What the README does establish is the shape of the thing. Dubbo is not a protocol library. Consumers discover provider instances dynamically from a registry, Zookeeper or Nacos among them, and then apply defined traffic strategies to those instances. Protocol choice is one axis of the configuration, and the alternatives on the next axis are where the framework decision lives. ## Two of the five version rows link to a tag that is not that version The version compatibility table is the most useful page in the repository and the least trustworthy. Each row offers a View Dependencies link into the dependency BOM. Check the tag in each URL against the version in the row. For 3.3.6 the link reads `dubbo-3.3.6`, and for 3.3.5 it reads `dubbo-3.3.5`. Then the 3.2.16 row links to `dubbo-3.2.5`, and the 3.1.11 row links to `dubbo-3.2.11`, which is a different minor line than the row it sits in. The Dubbo2 rows behave, with 2.7.23 and 2.6.12 pointing at themselves. The consequence is specific rather than cosmetic. If you are pinning 3.2.16, the BOM the README hands you is 3.2.5's, eleven patch releases behind, and if you are pinning 3.1.11 the link lands in the 3.2 line entirely. For a framework that pins a large transitive tree, auditing what your build will actually pull means resolving the BOM from `dubbo-dependencies-bom/pom.xml` yourself rather than trusting the table. ## dubbo-3.2.20 shipped four months after dubbo-3.3.6 The recent releases are dubbo-3.2.20 on 2026-05-17, dubbo-3.2.19 on 2025-11-13, and dubbo-3.3.6 on 2025-10-17. The default branch of the repository is 3.3, and the last push was on 2026-09-28. Put those together and the picture is unusual. The 3.2 line received the newer release and the more recent of the two tags, while the newer minor line stopped cutting releases in October 2025. Nothing in the README explains the ordering, and there is no column in the compatibility table telling you which branch is currently taking fixes. What that costs you is a decision rather than a bug. If you start on 3.3 you are on the branch the default branch name points at, and the table's newest 3.3 row is 3.3.6 with a 3.3.7-SNAPSHOT above it whose Dependencies cell reads Coming Soon. If you start on 3.2 you are on the line that shipped most recently and outside what the default branch tracks. Neither is wrong. Both need a deliberate choice, and the README will not make it for you. ## The Highlights column mixes feature names with maintenance labels Read the Highlights cells as a column and they contain two different kinds of statement. The 3.3.6 row lists capabilities: Mutiny Reactive Support, Affinity Router, Method-level TPS Limiting, a Spring 6 Security Plugin, and enhanced environment variable config. The 3.3.5 and 3.2.16 rows prefix their lists with the words Actively Maintained. The 3.1.11 row carries a warning that it is stable but not actively maintained. A feature list and a support commitment do not belong in the same column, and the effect is that the table cannot be sorted. The row above another is not always newer in practice, since 3.2.16 is described as maintained while the 3.3.6 row above it says nothing about support at all. The JDK column is the more reliable signal in the same table, and it moves independently of the version number. 3.3.7-SNAPSHOT is the only row claiming JDK 1.8 to 25, 3.3.6 and 3.3.5 stop at 21, 3.2.16 and 3.1.11 stop at 17, and the Dubbo2 rows are marked EOL with JDK 1.8 and JDK 1.6 to 1.7. If you are on a modern JDK, that column, not the Highlights column, is what should decide between 3.2 and 3.3. ## The contributing link points at master while the default branch is 3.3 The README's license badge and its dependency links both address the 3.3 branch. Its contribution section does not. The line reads: see our CONTRIBUTING guide, and the link behind it targets `blob/master/CONTRIBUTING.md`. On a repository whose default branch is 3.3, a link into `master` either resolves to a stale tree or to nothing at all. Either way, the first document a new contributor is sent to is the one the README does not keep on the branch it is describing. The rest of the contribution surface is spread across two systems rather than one. Issues go to GitHub Issues, questions and ideas to GitHub Discussions, and merges to GitHub Pull Requests, with a project board for help-wanted work. The build badges at the top of the README point at a GitHub Actions workflow, `build-and-test-pr.yml`, and at codecov, while the repository root carries a `Jenkinsfile` and a `Jenkinsfile.sonar`. A contributor reproducing a CI failure locally is matching two pipelines, not one. ## The multi-language promise is six other repositories The README opens by saying Dubbo supports multiple language implementations, and then links out for every one of them: Go to apache/dubbo-go, Python to apache/dubbo/py-client-for-apache-dubbo, PHP to apache/dubbo-php-framework, Erlang to apache/dubbo-erlang, Rust to apache/dubbo-rust, and Node.js and web to apache/dubbo-js. Six separate projects, six separate owners, six separate release cadences. The Java repository you are reading contains none of that code, and the compatibility table above covers Java JDK ranges only. There is no statement anywhere in the README about which version of the Java implementation a given Go or Python client expects, so a mixed-language estate is a version negotiation you run yourself. The honest reading of the ecosystem claim is that Dubbo is a set of implementations around one idea rather than one product with ports. That is a reasonable design, and it also means the word support in the opening line should be read as existence, not as a tested compatibility matrix. ## Which Dubbo Version Should I Use? has nothing under it The README contains a heading reading Which Dubbo Version Should I Use, a subheading reading Dubbo3, and then the next heading. There is no guidance between them, no recommendation, and no criteria for choosing between the two maintained lines described above. So the selection work lands on you, assembled from fragments: the JDK column for your runtime, the protocol list for your wire format, and the Highlights column with the caveat above. For the protocol axis the choices are Triple, which the documentation calls gRPC-compatible and which the 3.3.5 notes associate with gRPC and cURL, Dubbo2 over TCP, REST, and custom protocols. If Triple suits you, the framework is interoperable with gRPC clients on the wire while still owning discovery and traffic policy, which is the real difference from adopting gRPC as a protocol and nothing else. The module layout tells you where that logic lives before you read any of it. Eighteen `dubbo-*` directories sit at the root, among them `dubbo-cluster`, `dubbo-registry`, `dubbo-config`, `dubbo-configcenter`, `dubbo-remoting`, `dubbo-rpc`, `dubbo-serialization`, `dubbo-metadata`, and `dubbo-metrics`, and the names map one to one onto the features the README advertises. ## licenseCheck.sh runs on every file you add Apache Dubbo carries the standard ASF header machinery, and it is visible in the root rather than hidden in CI. The repository has a `LICENSE` file, a `NOTICE` file, a `.licenserc.yaml` configuration, and a `licenseCheck.sh` script at the top level, alongside a `codestyle/` directory, an `.editorconfig`, and `AGENTS.md`. For a contributor this is concrete rather than bureaucratic. A new Java file without the license header fails a check that runs in the same pipeline as the build, and `.licenserc.yaml` is the file that says which headers apply. Reading it before your first commit is faster than reading the failure. The build itself is Maven, with `pom.xml` at the root, a `dubbo-dependencies-bom` module for the pinned tree, `mvnw` and `mvnw.cmd` checked in alongside a `.mvn/` directory, and both `build` and `build.cmd` at the top for the two platforms. Everything needed to build without a globally installed Maven is in the tree, which is the one piece of onboarding friction this repository has clearly thought about. ## Conclusion Apache Dubbo earns its place when you already run a Java service estate and want one framework to carry discovery, traffic rules, and observability across it, and when gRPC compatibility matters more to you than schema-first contracts. Skip it for a new multi-language system, because the Go, Python, PHP, Erlang, Rust, and Node implementations live in six separate repositories with no shared release train. Verify three things before pinning a version. Resolve the dependency BOM yourself, because the 3.2.16 and 3.1.11 rows in the README link to the dubbo-3.2.5 and dubbo-3.2.11 tags. Decide whether you are on the 3.2 or the 3.3 line, given that dubbo-3.2.20 released on 2026-05-17 and dubbo-3.3.6 on 2025-10-17. And read the contributing guide from the 3.3 branch rather than the master link the README uses. ## FAQ ### Which version of Apache Dubbo should I use? The README does not make a recommendation. Its compatibility table lists 3.3.7-SNAPSHOT on JDK 1.8 to 25, 3.3.6 and 3.3.5 on JDK 1.8 to 21, 3.2.16 and 3.1.11 on JDK 1.8 to 17, and marks 2.7.23 and the 2.6.x and 2.5.x lines as EOL. Recent releases include dubbo-3.2.20 on 2026-05-17 and dubbo-3.3.6 on 2025-10-17. ### What protocols does Apache Dubbo support? The protocol list covers Triple, described as gRPC-compatible and associated with gRPC and cURL, Dubbo2 over TCP, REST, and custom protocols. On top of that the framework adds registry-based discovery through Zookeeper or Nacos, traffic strategies, metrics, and tracing. ### Does Apache Dubbo have implementations in other languages? The README links to six separate repositories: Go, Python, PHP, Erlang, Rust, and Node.js and web. Each is maintained outside the Java repository, and the version compatibility table in the README covers Java JDK ranges only. ## Sources - [Official documentation](https://dubbo.apache.org/) - [Official README](https://github.com/apache/dubbo#readme) - [Project repository](https://github.com/apache/dubbo) - [Release notes](https://github.com/apache/dubbo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-dubbo