Protobuf Editions

proto2 was open-sourced by Google in 2008 as the first public version of Protocol Buffers. It introduced the core concepts of .proto IDL, field numbers, wire types, and generated code.

Field labels in proto2: required: field must be present in every message. A message without a required field is considered incomplete. Using required prevents backward-compatible schema evolution – adding or removing required fields breaks existing producers and consumers. optional: field may or may not be present. If absent, the default value is used. optional fields can be checked for presence (HasField). repeated: zero or more values. Ordered list.

Extensions: proto2 introduced the extensions mechanism, allowing external .proto files to add fields to a message within a reserved number range. Largely superseded by proto3 Any and Editions features.

Default values in proto2: explicitly specified per field (default = value syntax). If not specified, the language default applies (0, empty string, false).

Proto2 is still widely used in codebases predating 2016. Existing proto2 schemas should not be migrated unless there is a specific reason – the migration risk outweighs any benefit for stable schemas.

proto3 was released in 2016 and became the standard edition for new Protobuf schemas. It simplified the language by removing required and making optional implicit.

Key changes from proto2: No required fields: all fields are implicitly optional. This was the most controversial change – required fields in proto2 were the primary source of schema evolution failures. No explicit default values: all fields default to the language zero value (0, empty string, false, empty bytes, nil enum). Custom defaults are not allowed. JSON mapping defined: every proto3 message has a well-defined JSON representation. Used by gRPC-web and REST transcoding. Maps: native map<K, V> syntax instead of a repeated message workaround. Oneof: mutually exclusive fields in a single union. Enum value 0 required: the first enum value must be zero and serves as the default.

Field presence in proto3: by default, proto3 scalar fields do not track presence. A field set to 0 / empty string / false is indistinguishable from an unset field on the wire. Use proto3 optional (optional keyword in proto3 syntax, added 2020) to restore HasField() semantics.

Packed repeated fields: proto3 makes packing the default for numeric repeated fields. proto2 required explicit [packed=true].

Editions replaces the coarse proto2/proto3 choice with fine-grained feature flags. Instead of selecting an edition that bundles a fixed set of behaviors, you choose the behaviors you want per file, per message type, or per field.

Core concept: every behavior that previously differed between proto2 and proto3 is now a named feature with explicit values. The edition sets the default values for all features; individual fields can override.

Key features in Editions 2023:

features.field_presence: EXPLICIT – field is always present if set, HasField() works for scalars (proto2 optional semantics) IMPLICIT – field presence not tracked; zero value = unset (proto3 default semantics) LEGACY_REQUIRED – equivalent to proto2 required (avoid in new schemas)

features.enum_type: OPEN – unknown enum values preserved as integers (proto3 behavior) CLOSED – unknown enum values trigger error (proto2 behavior)

features.repeated_field_encoding: PACKED – all values in one length-delimited block (proto3 default for numerics) EXPANDED – one tag per value (proto2 default)

features.utf8_validation: VERIFY – string fields are validated as valid UTF-8 NONE – no UTF-8 validation (proto2 legacy behavior)

features.message_encoding: LENGTH_PREFIXED – standard wire type 2 encoding DELIMITED – proto2 group encoding (wire types 3/4) for legacy compatibility

Migration: protoc and the buf CLI include tools to migrate proto2 and proto3 files to Editions syntax. The generated code behavior is unchanged during migration – Editions is a schema-level change, not a wire-format change.