Current versions
The table below reflects the versions tracked inversion.json at the repository root.
| Component | Version |
|---|---|
protoc | 35-dev |
| C++ | 7.35-dev |
| C# | 3.35-dev |
| Java | 4.35-dev |
| JavaScript | 3.35-dev |
| Objective-C | 5.35-dev |
| PHP | 5.35-dev |
| Python | 7.35-dev |
| Ruby | 4.35-dev |
| Rust | 4.35-dev |
Versions ending in
-dev are pre-release snapshots from the main branch. Stable release versions do not carry the -dev suffix.Versioning scheme
protoc (the compiler)
protoc releases use a single incrementing major version number (e.g., v27, v28). There is no minor or patch component for the compiler itself.
Language runtimes
Each language runtime is versioned independently using aMAJOR.MINOR scheme tied to the protoc release:
- The minor version tracks the protoc release (e.g., runtime
x.27was released alongsideprotocv27). - The major version is incremented when a breaking change is required for that specific language.
Support lifecycle
LTS vs regular releases
Some protoc releases are designated as Long-Term Support (LTS) releases. The"lts" field in version.json indicates whether the current development line will produce an LTS release.
- LTS releases receive bug fixes and security patches for an extended period after the initial release date.
- Regular releases are supported until the next regular or LTS release is available.
Check the release page on GitHub to identify which published versions carry the LTS designation.
Branch policy
- Most changes (features, bug fixes) target the
mainbranch and appear in the next major/minor release. - Bug fixes intended for a patch release (e.g.,
v27.1) must first land onmain, then be cherry-picked to the relevant release branch (e.g.,27.x).
Compatibility guarantees
Binary wire format
The binary wire format is permanently stable. A message serialized by any version of protobuf can be deserialized by any other version, past or future. Changes to the wire format are never accepted — any incompatible encoding would require an entirely new format specification.Text format
The text format is a debugging aid and is not guaranteed to be stable across versions. Do not use it for persistent storage or inter-process communication.Source (API) compatibility
- Public APIs are kept stable across minor and patch releases within a major version.
- Breaking API changes are avoided wherever possible. When a breaking change is unavoidable, it is first implemented in Google’s internal codebase and then propagated to the open-source repository. The major version of the affected language runtime is incremented.
- Changes to existing APIs are almost never accepted from external contributors. Stability and backwards compatibility are the top priority.