939ccbed42
An oft employed scheme for a lot of our APIs is to include an annotations field which is just a map of string to string. This usually allows folks using the API to send over metadata or auxiliary information without needing to get a new field added (especially where the field might not make sense for it to be a standalone field). I think having annotations for CreateSandbox make sense for this same use case. Signed-off-by: Danny Canter <danny@dcantah.dev> |
||
|---|---|---|
| .. | ||
| events | ||
| runtime | ||
| services | ||
| types | ||
| 1.0.pb.txt | ||
| 1.1.pb.txt | ||
| 1.2.pb.txt | ||
| doc.go | ||
| next.pb.txt | ||
| Protobuild.toml | ||
| README.md | ||
This directory contains the GRPC API definitions for containerd.
All defined services and messages have been aggregated into *.pb.txt
descriptors files in this directory. Definitions present here are considered
frozen after the release.
At release time, the current next.pb.txt file will be moved into place to
freeze the API changes for the minor version. For example, when 1.0.0 is
released, next.pb.txt should be moved to 1.0.txt. Notice that we leave off
the patch number, since the API will be completely locked down for a given
patch series.
We may find that by default, protobuf descriptors are too noisy to lock down API changes. In that case, we may filter out certain fields in the descriptors, possibly regenerating for old versions.
This process is similar to the process used to ensure backwards compatibility in Go.