Experimental features process documentation#5404
Conversation
knative-prow-robot
added
the
size/L
slinkydeveloper
changed the title
knative-prow-robot
added
the
do-not-merge/work-in-progress
Codecov Report
@@ Coverage Diff @@
## main #5404 +/- ##
=======================================
Coverage 82.72% 82.72%
=======================================
Files 197 197
Lines 6056 6056
=======================================
Hits 5010 5010
Misses 722 722
Partials 324 324 Continue to review full report at Codecov.
|
| [experimental.ValidateAPIFields()](https://github.com/knative/eventing/blob/917f57f0e68abbd0256c5fa4bff1ce2e83ffe78b/pkg/apis/experimental/api_validation.go#L13) | ||
| - Alternative to the above approach, If the feature affects a whole Resource, | ||
| and the API is a single value, that is not an object or an array of values, | ||
| use an annotation. Then, in the webhook, you can reject resources with |
There was a problem hiding this comment.
IMO, the choice between annotations vs spec field(s) depends on whether the feature is normative or not. An annotation might graduate into a field if it gains general consensus and applicability.
There was a problem hiding this comment.
For the clarification between normative and non-normative, see comment below.
IMO, the choice between annotations vs spec field(s) depends on whether the feature is normative or not.
Any suggestions to reword?
|
|
||
| - Disabled by default. | ||
| - No vendor is required to implement the new feature at this point, but it’s | ||
| encouraged to. |
There was a problem hiding this comment.
All depends on whether the feature is normative or not. A vendor is never required to implement a feature, unless the feature is normative and the vendor wants to be conformant wrt the new feature.
Maybe drop this line and say by definition an experimental feature is not normative so vendors don't have to support it in order to be compliant.
There was a problem hiding this comment.
In this commit 9536f95 I've added some clarifications between normative and non-normative. I think this document should not specify how to choose between normative and non-normative, because IMO depends on the feature itself and the discussions around it. I've just clarified that we cover both. How does it look like?
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
slinkydeveloper
changed the title
knative-prow-robot
removed
the
do-not-merge/work-in-progress
slinkydeveloper
force-pushed
the
experimental_features_process
branch
from
9089731 to
0362044
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: slinkydeveloper The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow-robot
added
the
approved
|
Rebased and added the links to the code, now it's ready to go! |
|
/lgtm |
3 participants
Signed-off-by: Francesco Guardiani francescoguard@gmail.com
This is a transcript of https://docs.google.com/document/d/1AoH0FyLeuHIg5snrlCKzELQv-NEA6bbjTU2Qv3zlW5k/edit?usp=sharing.
Blocked by #5214, because it contains some technical details I want to specify in the doc and link the appropriate code.
Proposed Changes