Changes Announced on July 10, 2026

Changes announced for Protocol Buffers on July 10, 2026.

Edition 2026

We are planning to release Protobuf Editions to the open source project in 36.x in Q3 2026.

These describe changes as we anticipate them being implemented, but due to the flexible nature of software some of these changes may not land or may vary from how they are described in this topic.

More documentation on Edition 2026 will be published in Feature Settings for Editions, including the migration guide.

Changes to Existing Features

This section details any existing features whose edition_default will be changed in Edition 2026.

`enforce_naming_style`: `STYLE2026`

The enforce_naming_style feature default will be updated to STYLE2026 to discourage common field naming collisions.

`default_symbol_visibility`: `STRICT`

https://protobuf.dev/programming-guides/symbol_visibility/

The default_symbol_visibility feature default will be updated to STRICT to encourage explicit use of export and local keywords and to, by default, disallow exporting nested types.

This feature encourages the best-practices defined in 1-1-1 Best Practice, which advocates for narrowly defined .proto files to limit dependency bloat.

New Features

This section details new features that will be introduced in Edition 2026.

JSON option: custom JSON string for values

Edition 2026 introduces a new JSON custom string option for enum values.

Prior to this release, we support custom keys using the json_name option. This new option extends this behavior to values.

Renaming may be desirable for conflict avoidance, help in migrations, or to satisfy external requirements.

Sample usage:

enum FOO {
   ...
   FOO_BAR = 5 [(pb.enumvalue.json).string = "custom_string_here"];
   ...
}

C++ option: namespace

Edition 2026 introduces the new namespace C++ option as a custom option to explicitly set the generated bindings namespace.

This allows C++ developers to specify binding language packaging independent of the .proto package.

Use the new namespace C++ option as an example:

import option "google/protobuf/cpp_options.proto";

package clock.time;

option (pb.file.cpp).namespace = "clock_time";

C++ options: C++ custom options moved out from descriptor.proto

In Edition 2026, C++ language-specific options are moved from descriptor.proto to separate custom option files.

To access these custom options for C++ in Edition 2026, import C++ language custom options from using ```protobuf import option “google/protobuf/cpp_features.proto”;

option features.(pb.cpp).repeated_type = PROXY


The proxy type returned follows STL container naming conventions.

Some methods currently available on `RepeatedPtrField`/`RepeatedField` will not
be available via proxies, such as `AddAllocated`/`ReleaseLast`,
data/mutable_data, `pointer_begin`/`pointer_end`, and `GetArena`.

Sample usage:

```cpp
// Before:
google::protobuf::RepeatedPtrField<MyMessage>* rpf = message.mutable_repeated_message();
MyMessage* element1 = rpf->Add();
const MyMessage& element2 = rpf->Get(0);
MyMessage* element3 = rpf->Mutable(1);

// After:
google::protobuf::RepeatedFieldProxy<MyMessage> rpf = message.mutable_repeated_message();
MyMessage& element1 = rpf.emplace_back();
const MyMessage& element2 = rpf.get(0);
MyMessage& element2 = rpf[0];

RepeatedFieldProxy has no public constructors (aside from a shallow copy constructor). Proxies can only be backed by repeated fields within a message. To aid with migration, we have introduced a new type, RepeatedFieldOrProxy, which is implicitly convertible from either a RepeatedFieldProxy or a legacy RepeatedPtrField/RepeatedField reference. It otherwise has an identical interface to RepeatedFieldProxy.

C#: Add option and code generation for nullable reference types

Edition 2026 adds support for generating C# code that utilizes nullable reference types.

This feature is opt-in and satisfies existing external user requests.

Grammar Changes

There is no new or removed grammar in Edition 2026.