4.7 KiB
Minimum Required Edition
Author: @mcy
Approved: 2022-11-15
A versioning mechanism for descriptors that ensures old runtimes do not load descriptors that are "too new."
Background
Suppose we decide to add a novel definition like
const int32 MY_CONSTANT = 42;
to the Protobuf language. This would entail a descriptor change to track the
values of constants, but they would not be loaded properly by older runtimes.
This document describes an addition to descriptor.proto
that prevents this
version mismatch issue.
Protobuf Editions intends to add the concept of an edition to Protobuf, which will be an approximately-annually incrementing value. Because of their annual nature, and because runtimes need to be updated to handle new features they implement regardless, we can use them as a poison pill for old runtimes that try to load descriptors that are "too new."
Overview
We propose adding a new field to FileDescriptorProto
:
optional string minimum_required_edition = ...;
This field would exist alongside the edition
field, and would have the
following semantics:
Every Protobuf runtime implementation must specify the newest edition whose
constructs it can handle (at a particular rev of that implementation). If that
edition is less than minimum_required_edition
, loading the descriptor must
fail.
"Less than" is defined per the edition total order given in Life of an Edition. To restate it, it is the following algorithm:
def edition_less_than(a, b):
parts_a = a.split(".")
parts_b = b.split(".")
for i in range(0, min(len(parts_a), len(parts_b))):
if int(parts_a[i]) < int(parts_b[i]): return True
return len(a) < len(b)
protoc
should keep track of which constructions require which minimum edition.
For example, if constants are introduced in edition 2025, but they are not
present in a file, protoc
should not require that runtimes understand
constants by picking a lower edition, like 2023 (assuming no other construct
requires a higher edition).
In particular, the following changes should keep the minimum edition constant, with all other things unchanged:
- An upgrade of the proto compiler.
- Upgrading the specified edition of a file via Prototiller.
Bootstrapping Concerns
"Epochs for descriptor.proto
" (not available externally) describes a potential
issue with bootstrapping. It is not the case here: minimum edition is only
incremented once a particular file uses a new feature. Since descriptor.proto
and other schemas used by protoc
and the backends would not use new features
immediately, introducing a new feature does not immediately stop the compiler
from being able to compile itself.
Concerns for Schema Producers
Schema producers should consider changes to their schemas that increase the minimum required edition to be breaking changes, since it will stop compiled descriptors from being loaded at runtime.
Recommendation
We recommend adding the aforementioned minimum required edition field, along with the semantics it entails. This logic should be implemented entirely in the protoc frontend.
Alternatives
Use a Non-Editions Version Number
Rather than using the editions value, use some other version number. This number
would be incremented rarely (3-5 year horizon). This is the approach proposed
in "Epochs for descriptor.proto
."
Pros
- Does not re-use the editions value for a semantically-different meaning; the edition remains being "just" a key into a table of features defaults.
Cons
- Introduces another version number to Protobuf that increments at its own cadence.
- Could potentially be confused with the edition value, even though they serve distinct purposes.
Minimum Required Edition Should Not Be Minimal
The proto compiler should not guarantee that the minimum required edition is as small as it could possibly be.
Pros
- Reduces implementation burden.
Cons
- This introduces situations where an upgrade of the proto compiler, or an innocuous change to a schema, can lead the the minimum required edition being incremented. This is a problem for schema producers.
Do Nothing
Pros
- Reduces churn in runtimes, since they do not need to implement new handling for new editions (as contrasted to just features) regularly.
- Avoids a situation where old software cannot load new descriptors at runtime.
Cons
- Commits us to never changing the descriptor wire format in
backwards-incompatible ways, which has far-reaching effects on evolution.
These consequences are discussed in "Epochs for
descriptor.proto
."