NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #31 most downloaded on PyPI
Last release 16 days ago
17 Sep 2026
Ships on a steady schedule
a new release about every 3 weeks
No release notes found
nothing matched a version
5 versions withdrawn
withdrawn after publishing
18 years old
222 releases · first in 2008
Remove OSReadLittle* due to alignment requirements.
Drop building wheel for python 3.4
One column per quarter.
Expose TextFormat.Printer and make it configurable. Deprecate the static methods.
protobuf_java_lite Bazel target. (#6177)Nothing published for this version
[c++17] Changed proto2::RepeatedPtrField iterators to no longer derive from the deprecated std::iterator class.
[c++17] Changed proto2::RepeatedPtrField iterators to no longer derive from the deprecated std::iterator class.
Avoid linking against libatomic in prebuilt protoc binaries
reflection.MakeClass() and reflection.ParseMessage() are deprecated.
Nothing published for this version
Nothing published for this version
Introduced workaround for Windows issue with std::atomic and std::once_flag initialization (#4777, #4773)
Added deprecation annotations to generated code for deprecated oneof fields.
__init__.py files to compiler and util subpackagesNothing published for this version
Nothing published for this version
Make C++ implementation C++11 only: we plan to require C++11 to build protobuf code starting from 3.6.0 release, after unknown fields semantic changes
discardUnknokwnFields API.timelib_update_ts).Any.php to use fully-qualified name for DescriptorPool.Google_Protobuf_discard_unknown for discarding unknown fields in
messages.Contains() API in map and repeated fields.Nothing published for this version
`ByteSize() and SpaceUsed() are deprecated.Use ByteSizeLong() and SpaceUsedLong()` instead
Preserve unknown fields in proto3: We are going to bring unknown fields back into proto3. In this release, some languages start to support preserving unknown fields in proto3, controlled by flags/options. Some languages also introduce explicit APIs to drop unknown fields for migration. Please read the change log sections by languages for details. See general timeline and plan and issues and discussions
Make C++ implementation C++11 only: we plan to require C++11 to build protobuf code starting from 3.5.0 or 3.6.0 release, after unknown fields semantic changes are finished. Please join this github issue to provide your feedback.
reserve keyword now supports max in field number ranges, e.g. reserve 1000 to max;Proto3 messages are now able to preserve unknown fields. The default behavior is still to drop unknowns, which will be flipped in a future release. If you rely on unknowns fields being dropped. Please use Message::DiscardUnknownFields() explicitly.
Packable proto3 fields are now packed by default in serialization.
Following C++11 features are introduced when C++11 is available:
std::initializer_listExperimental Table-Driven parsing and serialization available to test. To enable it, pass in table_driven_parsing table_driven_serialization protoc generator flags for C++
$ protoc --cpp_out=table_driven_parsing,table_driven_serialization:./ test.proto
lite generator parameter supported by the generator. Once set, all generated files, use lite runtime regardless of the optimizer_for setting in the .proto file.
Various optimizations to make C++ code more performant on PowerPC platform
Fixed maps data corruption when the maps are modified by both reflection API and generated API.
Deterministic serialization on maps reflection now uses stable sort.
file() accessors are introduced to various *Descriptor classes to make writing template function easier.
ByteSize() and SpaceUsed() are deprecated.Use ByteSizeLong() and SpaceUsedLong() instead
Consistent hash function is used for maps in DEBUG and NDEBUG build.
"using namespace std" is removed from stubs/common.h
Various performance optimizations and bug fixes
Introduced new parser API DiscardUnknownFieldsParser in preparation of proto3 unknown fields preservation change. Users who want to drop unknown fields should migrate to use this new parser API. For example:
Parser<Foo> parser = DiscardUnknownFieldsParser.wrap(Foo.parser());
Foo foo = parser.parseFrom(input);
Introduced new TextFormat API printUnicodeFieldValue() that prints field value without escaping unicode characters.
Added Durations.compare(Duration, Duration) and Timestamps.compare(Timestamp, Timestamp).
JsonFormat now accepts base64url encoded bytes fields.
Optimized CodedInputStream to do less copies when parsing large bytes fields.
Optimized TextFormat to allocate less memory when printing.
SerializeToString(self, **kwargs), deterministic parameter is accepted for deterministic serialization.__repr__ support for repeated field in cpp implementation.php_generic_service=true to enable generating service interface.IReadOnlyDictionary<K,V> in MapField<K,V>[jstype = JS_STRING] on the field.Added whole-message deprecation, which decorates the class with [Obsolete].
Added protoc version number to protoc plugin protocol. It can be used by protoc plugin to detect which version of protoc is used with the plugin and m
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Added MessageLite::ByteSizeLong() that’s equivalent to MessageLite::ByteSize() but returns the value in size_t. Useful to check whether a message is o
We have added the proto3 support for PHP via both a pure PHP package and a native c extension. The pure PHP package is intended to provide usability to wider range of PHP platforms, while the c extension is intended to provide higher performance. Both implementations provide the same runtime APIs and share the same generated code. Users don’t need to re-generate code for the same proto definition when they want to switch the implementation later. The pure PHP package is included in the php/src directory, and the c extension is included in the php/ext directory.
Both implementations provide idiomatic PHP APIs:
Unlike several existing third-party PHP implementations for protobuf, our implementations are built on a "strongly-typed" philosophy: message fields and array/map containers will throw exceptions eagerly when values of the incorrect type (not including those that can be type converted, e.g., double <-> integer <-> numeric string) are inserted.
Currently, pure PHP runtime supports php5.5, 5.6 and 7 on linux. C extension runtime supports php5.5 and 5.6 on linux.
See php/README.md for more details about installment. See https://developers.google.com/protocol-buffers/docs/phptutorial for more details about APIs.
Introduced an ExperimentalApi annotation. Annotated APIs are experimental and are subject to change in a backward incompatible way in future releases.
This change log summarizes all the changes since the last stable release (v2.6.1). See the last section about changes since v3.0.0-beta-4.
Introduced Protocol Buffers language version 3 (aka proto3).
When protocol buffers was initially open sourced it implemented Protocol Buffers language version 2 (aka proto2), which is why the version number started from v2.0.0. From v3.0.0, a new language version (proto3) is introduced while the old version (proto2) will continue to be supported.
The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform. In proto3, the language is simplified, both for ease of use and to make it available in a wider range of programming languages. At the same time a few features are added to better support common idioms found in APIs.
The following are the main new features in language version 3:
A new notion "syntax" is introduced to specify whether a .proto file uses proto2 or proto3:
// foo.proto
syntax = "proto3";
message Bar {...}
If omitted, the protocol buffer compiler generates a warning and "proto2" is used as the default. This warning will be turned into an error in a future release.
We recommend that new Protocol Buffers users use proto3. However, we do not generally recommend that existing users migrate from proto2 from proto3 due to API incompatibility, and we will continue to support proto2 for a long time.
Other significant changes in proto3.
Explicit "optional" keyword are disallowed in proto3 syntax, as fields are optional by default; required fields are no longer supported.
Removed non-zero default values and field presence logic for non-message fields. e.g. has_xxx() methods are removed; primitive fields set to default values (0 for numeric fields, empty for string/bytes fields) will be skipped during serialization.
Group fields are no longer supported in proto3 syntax.
Changed repeated primitive fields to use packed serialization by default in proto3 (implemented for C++, Java, Python in this release). The user can still disable packed serialization by setting packed to false for now.
Added well-known type protos (any.proto, empty.proto, timestamp.proto, duration.proto, etc.). Users can import and use these protos just like regular proto files. Additional runtime support are available for each language.
Proto3 JSON is supported in several languages (fully supported in C++, Java, Python and C# partially supported in Ruby). The JSON spec is defined in the proto3 language guide:
https://developers.google.com/protocol-buffers/docs/proto3#json
We will publish a more detailed spec to define the exact behavior of proto3-conformant JSON serializers and parsers. Until then, do not rely on specific behaviors of the implementation if it’s not documented in the above spec.
Proto3 enforces strict UTF-8 checking. Parsing will fail if a string field contains non UTF-8 data.
Introduced new language implementations (C#, JavaScript, Ruby, Objective-C) to proto3.
Added support for map fields (implemented in both proto2 and proto3). Map fields can be declared using the following syntax:
message Foo {
map<string, string> values = 1;
}
The data of a map field is stored in memory as an unordered map and can be accessed through generated accessors.
Added a "reserved" keyword in both proto2 and proto3 syntax. Users can use this keyword to declare reserved field numbers and names to prevent them from being reused by other fields in the same message.
To reserve field numbers, add a reserved declaration in your message:
message TestMessage {
reserved 2, 15, 9 to 11, 3;
}
This reserves field numbers 2, 3, 9, 10, 11 and 15. If a user uses any of these as field numbers, the protocol buffer compiler will report an error.
Field names can also be reserved:
message TestMessage {
reserved "foo", "bar";
}
Added a deterministic serialization API (currently available in C++). The deterministic serialization guarantees that given a binary, equal messages will be serialized to the same bytes. This allows applications like MapReduce to group equal messages based on the serialized bytes. The deterministic serialization is, however, NOT canonical across languages; it is also unstable across different builds with schema changes due to unknown fields. Users who need canonical serialization, e.g. persistent storage in a canonical form, fingerprinting, etc, should define their own canonicalization specification and implement the serializer using reflection APIs rather than relying on this API.
Added a new field option "json_name". By default proto field names are converted to "lowerCamelCase" in proto3 JSON format. This option can be used to override this behavior and specify a different JSON name for the field.
Added conformance tests to ensure implementations are following proto3 JSON specification.
Added arena allocation support (for both proto2 and proto3).
Profiling shows memory allocation and deallocation constitutes a significant fraction of CPU-time spent in protobuf code and arena allocation is a technique introduced to reduce this cost. With arena allocation, new objects are allocated from a large piece of preallocated memory and deallocation of these objects is almost free. Early adoption shows 20% to 50% improvement in some Google binaries.
To enable arena support, add the following option to your .proto file:
option cc_enable_arenas = true;
The protocol buffer compiler will generate additional code to make the generated message classes work with arenas. This does not change the existing API of protobuf messages and does not affect wire format. Your existing code should continue to work after adding this option. In the future we will make this option enabled by default.
To actually take advantage of arena allocation, you need to use the arena APIs when creating messages. A quick example of using the arena API:
{
google::protobuf::Arena arena;
// Allocate a protobuf message in the arena.
MyMessage* message = Arena::CreateMessage<MyMessage>(&arena);
// All submessages will be allocated in the same arena.
if (!message->ParseFromString(data)) {
// Deal with malformed input data.
}
// Must not delete the message here. It will be deleted automatically
// when the arena is destroyed.
}
Currently arena allocation does not work with map fields. Enabling arenas in a .proto file containing map fields will result in compile errors in the generated code. This will be addressed in a future release.
Added runtime support for the Any type. To use Any in your proto file, first import the definition of Any:
// foo.proto
import "google/protobuf/any.proto";
message Foo {
google.protobuf.Any any_field = 1;
}
message Bar {
int32 value = 1;
}
Then in C++ you can access the Any field using PackFrom()/UnpackTo() methods:
Foo foo;
Bar bar = ...;
foo.mutable_any_field()->PackFrom(bar);
...
if (foo.any_field().IsType<Bar>()) {
foo.any_field().UnpackTo(&bar);
...
}
In text format, the entries of a map field will be sorted by key.
Introduced new utility functions/classes in the google/protobuf/util directory:
Introduced a deterministic serialization API in CodedOutputStream::SetSerializationDeterministic(bool). See the notes about deterministic serialization in the General section.
ByteOutput interface. This is similar to
OutputStream but provides semantics for lazy writing (i.e. no
immediate copy required) of fields that are considered to be immutable.ByteString now supports writing to a ByteOutput, which will directly
expose the internals of the ByteString (i.e. byte[] or ByteBuffer)
to the ByteOutput without copying.CodedOutputStream now supports writing to a ByteOutput. ByteString
instances that are too large to fit in the internal buffer will be
(lazily) written to the ByteOutput directly.ByteString fields to avoid
duplication of these fields entirely. Such an application can supply a
ByteOutput that chains together the chunks received from
CodedOutputStream before forwarding them onto the IO system.CodedOutputStream
sun.misc.Unsafe where possible to perform fast
access to byte[] and ByteBuffer values and avoiding unnecessary
range checking.ByteBuffer-backed CodedOutputStream now writes directly to the
ByteBuffer rather than to an intermediate array.We have added proto3 support for Ruby via a native C/JRuby extension.
For the moment we only support proto3. Proto2 support is planned, but not yet implemented. Proto3 JSON is supported, but the special JSON mappings for the well-known types are not yet implemented.
The Ruby extension itself is included in the ruby/ directory, and details on
building and installing the extension are in ruby/README.md. The extension
is also be published as a Ruby gem. Code generator support is included as
part of protoc with the --ruby_out flag.
The Ruby extension implements a user-friendly DSL to define message types
(also generated by the code generator from .proto files). Once a message
type is defined, the user may create instances of the message that behave in
ways idiomatic to Ruby. For example:
foo and setter method foo=).#to_s, #dup, and the like, are
present.Unlike several existing third-party Ruby extensions for protobuf, this extension is built on a "strongly-typed" philosophy: message fields and array/map containers will throw exceptions eagerly when values of the incorrect type are inserted.
See ruby/README.md for details.
Objective-C includes a code generator and a native objective-c runtime library. By adding “--objc_out” to protoc, the code generator will generate a header(.pbobjc.h) and an implementation file(.pbobjc.m) for each proto file.
In this first release, the generated interface provides: enums, messages, field support(single, repeated, map, oneof), proto2 and proto3 syntax support, parsing and serialization. It’s compatible with ARC and non-ARC usage. In addition, users can access it via the swift bridging header.
COLOR with a value
COLOR_LIGHT_GRAY would generate a value of just LightGray).goog.require().Supported Proto3 lite-runtime in Java for mobile platforms. A new "lite" generator parameter was introduced in the protoc for C++ for Proto3 syntax messages. Example usage:
./protoc --cpp_out=lite:$OUTPUT_PATH foo.proto
The protoc will treat the current input and all the transitive dependencies as LITE. The same generator parameter must be used to generate the dependencies.
In Proto3 syntax files, "optimized_for=LITE_RUNTIME" is no longer supported.
For Java, --javalite_out code generator is supported as a separate compiler plugin in a separate branch.
Performance optimizations for Java Lite runtime on Android: - Reduced allocations - Reduced method overhead after ProGuarding - Reduced code size after ProGuarding
Java Lite protos now implement deep equals/hashCode/toString
a.string_field = “X”, we now call
#encode(UTF-8) on the string and freeze the copy. This saves you from
needing to ensure the string is already encoded as UTF-8. It also prevents
you from mutating the string after it has been assigned (this is how we
ensure it stays valid UTF-8).foo.proto is now foo_pb.rb instead of just
foo.rb. This makes it easier to see which imports/requires are from
protobuf generated code, and also prevents conflicts with any foo.rb file
you might have written directly in Ruby. It is a backward-incompatible
change: you will need to update all of your require statements.foo_bar, we now translate this to the Ruby module
FooBar. This is more idiomatic Ruby than what we used to do (Foo_bar).undefined or null when they are unset. You can test for presence
explicitly by calling hasFoo(), which we now generate for scalar fields in
proto2.javalite branch. Both lite runtime and protoc artifacts will be available
in Maven.Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Added atomicops support for Solaris.
Files, services, enums, messages, methods and enum values can be marked as deprecated now.
Added oneofs(unions) feature. Fields in the same oneof will share memory and at most one field can be set at the same time. Use the oneof keyword to define a oneof like:
message SampleMessage {
oneof test_oneof {
string name = 4;
YourMessage sub_message = 9;
}
}
Files, services, enums, messages, methods and enum values can be marked as deprecated now.
Added Support for list values, including lists of mesaages, when parsing text-formatted protos in C++ and Java.
For example: foo: [1, 2, 3]
New notion "import public" that allows a proto file to forward the content it imports to its importers. For example,
New notion "import public" that allows a proto file to forward the content it imports to its importers. For example,
// foo.proto
import public "bar.proto";
import "baz.proto";
// qux.proto
import "foo.proto";
// Stuff defined in bar.proto may be used in this file, but stuff from
// baz.proto may NOT be used without importing it explicitly.
This is useful for moving proto files. To move a proto file, just leave a single "import public" in the old proto file.
New enum option "allow_alias" that specifies whether different symbols can be assigned the same numeric value. Default value is "true". Setting it to false causes the compiler to reject enum definitions where multiple symbols have the same numeric value. Note: We plan to flip the default value to "false" in a future release. Projects using enum aliases should set the option to "true" in their .proto files.
Comments in proto files are now collected and put into generated code as comments for corresponding classes and data members.
Added Parser to parse directly into messages without a Builder. For example,
Foo foo = Foo.PARSER.ParseFrom(input);
Using Parser is ~25% faster than using Builder to parse messages.
Added getters/setters to access the underlying ByteString of a string field directly.
ByteString now supports more operations: substring(), prepend(), and append(). The implementation of ByteString uses a binary tree structure to support these operations efficiently.
New method findInitializationErrors() that lists all missing required fields.
Various code size and speed optimizations.
Fixed the frendship problem for old compilers to make the library now gcc 3 compatible again.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →