<p dir="auto">The unversioned concept is not needed.  Every object demonstrably has a schema that constitutes a single version (there is no object without a version).  Unversioned is a limited concept intended to solve two cases - api objects that are not retrieved in the context of a locked version (/apis/, /api/, Status errors encountered outside a scheme), and the reuse of objects across versions.  The latter is better served by type aliasing (declaring that v1beta1 Status has the equivalent to schema of v1 Status) or type duplication (copy v1 Status into v1beta1 and register it).  The former still has a schema that requires exposure through swagger, and for which certain code that already handles versioned code is directly better.  The contract of backwards compatibility for unversioned API endpoints requires that we not deliver backwards incompatible schemas to clients, but that does not limit us to the exposure of new API groups on different server implementations that have newer implementations of status.</p>
<p dir="auto">The unversioned package should be changed:</p>
<ul dir="auto">
<li>We should create a "v1" unversioned package (indicating these are versioned types) that contains everything in "v1".
<ul dir="auto">
<li>The parent package name should be renamed to "common" or "server"</li>
<li>No backwards incompatible changes are allowed in this package (same statement as today)</li>
<li>We can put common types into here that individual implementations of APIs get to pick from - for instance, an API can choose to take v1 Status or v2 Status</li>
</ul>
</li>
<li>API status, when returned by an API versioned url path (<code class="notranslate">/apis/group/version/*</code>) should be versioned - the Go type <code class="notranslate">common/v1/Status</code> should be registered into each API version under the name <code class="notranslate">Status</code>, and the returned group and version of the object from the API would be the group and version they are under</li>
<li>Top level, non-version-lockedAPIs should return <code class="notranslate">kind: "Status", version: "v1"</code> which is backwards compatible with what we launched with.  That means they obey the schema registered under "version 1" which is in the legacy group.</li>
<li>Any new top level object returned from a non-locked API today should return version "v1" (APIGroup, others)
<ul dir="auto">
<li>In the future, when we have to add incompatible objects, we will rev the whole server endpoint (<code class="notranslate">/apis.2/</code> etc)</li>
</ul>
</li>
</ul>
<p dir="auto">The changes above mean that there is no need for internal versions to know about "unversioned" - they always have an API group they serve from (unversioned is v1).  Encoding will properly fail if the type is not registered and locked into a type.  We will declare that any object retrieved outside of a versioned endpoint must be added to the <code class="notranslate">common/v1</code> package, and otherwise requires no special handling.</p>
<p dir="auto">Examples:</p>
<ul dir="auto">
<li><code class="notranslate">/api/</code> returns <code class="notranslate">v1 Status</code></li>
<li><code class="notranslate">/apis/</code> returns <code class="notranslate">v1 APIGroupList</code></li>
<li>a 403 error on <code class="notranslate">/api/</code> returns <code class="notranslate">v1 Status</code></li>
<li>a 403 error on <code class="notranslate">/api/v1/foo</code> returns <code class="notranslate">v1 Status</code></li>
<li>a 403 error on <code class="notranslate">/apis/extensions/v1beta1/foo</code> returns <code class="notranslate">v1beta1 Status</code></li>
<li>Swagger returns <code class="notranslate">v1beta1 Status</code> for extensions that has the same schema as <code class="notranslate">v1 Status</code></li>
</ul>
<p dir="auto">@kubernetes/sig-api-machinery</p>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.):</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.):<br>
---Handling environments like DEV, TEST, CERT, PROD</p>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):<br>
Feature Request</p>

<p dir="auto">Looking for an option to differentiate various environments</p>
<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>:</li>
<li><strong>OS</strong> (e.g. from /etc/os-release):</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>):</li>
<li><strong>Install tools</strong>:</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto">Others<br>
<strong>What happened</strong>:<br>
Looking for an option to handle DEV, TEST, CERT and PROD environments.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
I would like to have these environments in different clusters</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:<br>
Looking for best practice</p>