docs: Fix spelling errors in API docs (#16611)

This includes minor spelling and grammar fixes.

Signed-off-by: Lachlan Cooper <lachlancooper@gmail.com>

Mirrored from https://github.com/envoyproxy/envoy @ 8cb649ee2b4d1296d5a8b8c1d7bef2be2a694f88
pull/624/head
data-plane-api(Azure Pipelines) 4 years ago
parent db2f5481fd
commit 98ff14246c
  1. 6
      API_VERSIONING.md
  2. 2
      STYLE.md

@ -21,12 +21,12 @@ https://github.com/envoyproxy/envoy/issues/8416.
In everyday discussion and GitHub labels, we refer to the `v2`, `v3`, `vN`, `...` APIs. This has a
specific technical meaning. Any given message in the Envoy API, e.g. the `Bootstrap` at
`envoy.config.bootstrap.v3.Boostrap`, will transitively reference a number of packages in the Envoy
`envoy.config.bootstrap.v3.Bootstrap`, will transitively reference a number of packages in the Envoy
API. These may be at `vN`, `v(N-1)`, etc. The Envoy API is technically a DAG of versioned package
namespaces. When we talk about the `vN xDS API`, we really refer to the `N` of the root
configuration resources (e.g. bootstrap, xDS resources such as `Cluster`). The
v3 API bootstrap configuration is `envoy.config.bootstrap.v3.Boostrap`, even
though it might might transitively reference `envoy.service.trace.v2`.
v3 API bootstrap configuration is `envoy.config.bootstrap.v3.Bootstrap`, even
though it might transitively reference `envoy.service.trace.v2`.
# Backwards compatibility

@ -230,7 +230,7 @@ xDS APIs:
breaking changes where there is no substantial gain in functionality,
performance, security or implementation simplification. We will tolerate
technical debt in the API itself, e.g. in the form of vestigial deprecated
fields or reduced ergnomics (such as not using `oneof` when we would prefer
fields or reduced ergonomics (such as not using `oneof` when we would prefer
to), in order to meet this principle.
* Namespaces for extensions, metadata, etc. use a reverse DNS naming scheme,

Loading…
Cancel
Save