Version Support (original) (raw)

A list of the support windows provided for language implementations.

Currently Supported Release Versions

Minimum Supported Gencode

While each language runtime has a minimum supported gencode version, we recommend regenerating your gencode with every release update. Support for older generated code exists solely to ensure backwards compatibility for existing projects, not for new adoption of older gencode versions.

SeeCross Version Runtime Guaranteefor more information.

Supported Editions

Protobuf release versions are independent of edition “versions” which determine the syntax used by a .proto file (proto2, proto3, 2023, 2024).

Currently, latest protoc supports handling of all cases. At some future time, a protoc release may drop support for some set of .proto inputs, but we have no concrete plans to do so today.

As new Editions are added, a sufficiently new protoc is needed to use files which use that Edition:

Numbering Scheme

Version numbers use SemVer conventions. In the version “3.21.7”, “3” is the major version, “21” is the minor version, and “7” is the patch number.

Protobuf releases use only a minor.point format, for example 34.1.

Each language runtime shares this minor.point but uses a language-specific major version. For example, Protobuf release 34.1 corresponds to Java runtime4.34.1 and C# runtime 3.34.1. We recommend using protoc 34.1 with Java4.34.1 and C# 3.34.1.

This scheme unifies release numbers across all languages while decoupling major version changes. For example, release 30.0 contained breaking changes for Python but not for Java. Therefore, Python advanced from 5.29.0 to 6.30.0, while Java advanced from 4.29.0 to 4.30.0.

We introduced this versioning scheme in 2022 with release 21. Previously, all languages used major version 3.

Release Cadence

Protobuf releases updates quarterly. We target major (breaking) releases for Q1. Security fixes and other urgent needs will require additional releases.

Ourlibrary breaking change policydefines our support windows.

Enforcing documented language, tooling, platform, and library support policies is not a breaking change. For example, we might drop support for an End-of-Life (EOL) language version without bumping the major version.

What Changes in a Release?

The binary wire format never changes. You can read old binary wire format data with newer Protobuf versions. You can read new binary wire format data with older Protobuf versions (as long as the .proto syntax is supported). ProtoJSON format offers these same stability guarantees. TextProto is intended to be used for configuration use-cases and should not be used as a wire format between two servers.

The descriptor.proto schema can change. In minor or patch releases, we might add or deprecate elements (messages, fields, enums, enum values, editions, or editions features). In releases with breaking changes (major releases), we might remove deprecated elements.

The .proto language grammar can change with new Editions. In minor release, support for a new Edition may be added, which will add language constructs or deprecate existing behaviors. Adopting a new Edition may require client code updates. A future release may drop support for an old syntax. However, we have no current concrete plans to do so.

Gencode and runtime APIs can change. Minor and patch releases include purely additive or source-compatible updates. You can simply recompile your code. Releases with breaking changes (major releases) introduce incompatible API changes that require callsite updates. We minimize these changes. Bug fixes for undefined behavior do not require a major release.

**Operating system, programming language, and tooling support can change.**Minor or patch releases might add or drop support for specific operating systems, programming languages, or tools. See thefoundational support matricesfor supported languages.

In general:

• Minor or patch releases include purely additive or source-compatible updates based on ourCross Version Runtime Guarantee.
• Major releases might remove functionality, features, or change APIs in ways that require updates to callsites.

Support Duration

We always support the most recent release. Releasing a new minor version immediately ends support for the previous minor version. Releasing a major version ends support for the previous major version four quarters later.

For example, Protobuf Python 5.26.0 launched in Q1 2024. Therefore, Protobuf Python 4.25.x support ended in Q1 2025.

The following sections detail support timelines for each language. Future plans appear in italics and might change.

Legend

C++

Release Support Dates

Release Support Chart

C++ Tooling, Platform, and Library Support

Protobuf follows theFoundational C++ Support Policy. For supported versions, see theFoundational C++ Support Matrix.

C#

Release Support Dates

Release Support Chart

C# Platform and Library Support

Protobuf is committed to following the platform and library support policy described in.NET Support Policy. For specific versions supported, seeFoundational .NET Support Matrix.

Java

Release Support Dates

Release Support Chart

Java Platform and Library Support

Protobuf follows theJava Support Policy. For supported versions, see theFoundational Java Support Matrix.

On Android, Protobuf supports the minimum SDK version defined byGoogle Play services or the default inJetpack. We support whichever version is lower.

PHP

Release Support Dates

Release Support Chart

PHP Platform and Library Support

Protobuf follows thePHP Support Policy. For supported versions, see theFoundational PHP Support Matrix.

Python

Release Support Dates

Release Support Chart

Python Platform and Library Support

Protobuf follows thePython Support Policy. For supported versions, see theFoundational Python Support Matrix.

Ruby

Release Support Dates

Release Support Chart

Ruby Platform and Library Support

Protobuf follows theRuby Support Policy. For supported versions, see theFoundational Ruby Support Matrix.

We do not officially support JRuby. However, we provide unofficial, best-effort support for the latest JRuby version. This targets compatibility with our minimum supported Ruby version.