Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: updating runtime guard policy #10983

Merged
merged 5 commits into from
Apr 30, 2020
Merged

docs: updating runtime guard policy #10983

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4d0bc49
docs: updating runtime guard policy
alyssawilk Apr 28, 2020
924f546
not all changes are created equal
alyssawilk Apr 28, 2020
2f5a5da
reviewer comments
alyssawilk Apr 28, 2020
d28eacf
reviewer comments
alyssawilk Apr 29, 2020
b81cdf8
reviewer comments
alyssawilk Apr 30, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,10 +125,14 @@ versioning guidelines:

# Runtime guarding

Some high risk changes in Envoy are deemed worthy of runtime guarding. Instead of just replacing
Some changes in Envoy are deemed worthy of runtime guarding. Instead of just replacing
old code with new code, both code paths are supported for between one Envoy release (if it is
guarded due to performance concerns) and a full deprecation cycle (if it is a high risk behavioral
change).
change). Generally as a community we try to guard both high risk changes (major
refactors such as replacing Envoy's buffer implementation) and most user-visible
non-config-guarded changes to protocol processing (for example additions or changes to HTTP headers or
how HTTP is serialized out) for non-alpha features. Feel free to tag @envoyproxy/maintainers
if you aren't sure if a given change merits runtime guarding.

The canonical way to runtime guard a feature is
```
Expand Down Expand Up @@ -156,8 +160,9 @@ time.
Runtime guarded features may either set true (running the new code by default) in the initial PR,
after a testing interval, or during the next release cycle, at the PR author's and reviewing
maintainer's discretion. Generally all runtime guarded features will be set true when a
release is cut, and the old code path will be deprecated at that time. Runtime features
are set true by default by inclusion in
release is cut. Old code paths for refactors can be cleaned up after a release and there has been
some production run time. Old code for behavioral changes will be deprecated after six months.
Runtime features are set true by default by inclusion in
[source/common/runtime/runtime_features.h](https://github.com/envoyproxy/envoy/blob/master/source/common/runtime/runtime_features.h)

There are four suggested options for testing new runtime features:
Expand Down
1 change: 1 addition & 0 deletions PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,5 +7,6 @@ Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Document more fully in https://github.com/envoyproxy/envoy/blob/master/PULL_REQUESTS.md with links to the contributing guide, etc.?

[Optional Fixes #Issue]
[Optional Deprecated:]