From 182aeb686ffef1750519a4d2acc69124a70a2ab1 Mon Sep 17 00:00:00 2001 From: Brian Grant Date: Thu, 23 Mar 2017 14:52:00 -0700 Subject: Update api-conventions.md Clarify validation change rules. --- contributors/devel/api-conventions.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/contributors/devel/api-conventions.md b/contributors/devel/api-conventions.md index e05224a4..134ec374 100644 --- a/contributors/devel/api-conventions.md +++ b/contributors/devel/api-conventions.md @@ -1471,10 +1471,13 @@ like "larger than", "bigger than", "more than", "higher than", etc. on both mutation and read. Old clients must continue to function properly while only manipulating the old field. New clients must be able to function properly while only manipulating the new field. -* Validation rules on spec fields can be relaxed but not strengthened -- any requests that - previously worked must continue to work. The opposite is true for status fields. Note that changing - any validation rules always has the potential of breaking some client, since it changes the - assumptions about part of the API, similar to adding new enum values. +* Changing any validation rules always has the potential of breaking some client, since it changes the + assumptions about part of the API, similar to adding new enum values. Validation rules on spec fields can + neither be relaxed nor strengthened. Strengthening cannot be permitted because any requests that previously + worked must continue to work. Weakening validation has the potential to break other consumers and generators + of the API resource. Status fields whose writers are under our control (e.g., written by non-pluggable + controllers), may potentially tighten validation, since that would cause a subset of previously valid + values to be observable by clients. [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/api-conventions.md?pixel)]() -- cgit v1.2.3