<p>I have a few questions regarding the configMap versioning.</p>
<ol>
<li><p>Is it possible to use a specific version of a configMap in the deployment file?</p>
</li>
<li><p>I don't see any API's to get list of versions. How to get the list of versions?</p>
</li>
<li><p>Is it possible to compare configMap between versions?</p>
</li>
<li><p>How to control the number of versions?</p>
</li>
</ol>

user1578872
<blockquote>
  <p>Is it possible to use a specific version of a configMap in the deployment file?</p>
</blockquote>

<p>Not really.<br>
The closest notion of a "version" is resourceVersion, but that is not for the user to directly act upon.</p>

<p>See <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#concurrency-control-and-consistency" rel="nofollow noreferrer">API conventions: concurrency control and consistency</a>:</p>

<blockquote>
  <p>Kubernetes leverages the concept of resource versions to achieve optimistic concurrency. All Kubernetes resources have a "<code>resourceVersion</code>" field as part of their metadata. This <code>resourceVersion</code> is a string that identifies the internal version of an object that can be used by clients to determine when objects have changed.<br>
  When a record is about to be updated, it's version is checked against a pre-saved value, and if it doesn't match, the update fails with a <code>StatusConflict</code> (HTTP status code 409).</p>
  
  <p>The <code>resourceVersion</code> is changed by the server every time an object is modified. If <code>resourceVersion</code> is included with the <code>PUT</code> operation the system will verify that there have not been other successful mutations to the resource during a read/modify/write cycle, by verifying that the current value of <code>resourceVersion</code> matches the specified value.</p>
  
  <p>The <code>resourceVersion</code> is currently backed by etcd's <code>modifiedIndex</code>.<br>
  However, it's important to note that the application should not rely on the implementation details of the versioning system maintained by Kubernetes. We may change the implementation of <code>resourceVersion</code> in the future, such as to change it to a timestamp or per-object counter.</p>
  
  <p>The only way for a client to know the expected value of <code>resourceVersion</code> is to have received it from the server in response to a prior operation, typically a <code>GET</code>. This value MUST be treated as opaque by clients and passed unmodified back to the server.<br>
  Clients should not assume that the resource version has meaning across namespaces, different kinds of resources, or different servers.<br>
  Currently, the value of <code>resourceVersion</code> is set to match etcd's sequencer. You could think of it as a logical clock the API server can use to order requests. 
  However, we expect the implementation of <code>resourceVersion</code> to change in the future, such as in the case we shard the state by kind and/or namespace, or port to another storage system.</p>
  
  <p>In the case of a conflict, the correct client action at this point is to <code>GET</code> the resource again, apply the changes afresh, and try submitting again.<br>
  This mechanism can be used to prevent races like the following:</p>
</blockquote>

<pre><code>Client #1                                  Client #2
GET Foo                                    GET Foo
Set Foo.Bar = "one"                        Set Foo.Baz = "two"
PUT Foo                                    PUT Foo
</code></pre>

<blockquote>
  <p>When these sequences occur in parallel, either the change to <code>Foo.Bar</code> or the change to <code>Foo.Baz</code> can be lost.</p>
  
  <p>On the other hand, when specifying the <code>resourceVersion</code>, one of the <code>PUT</code>s will fail, since whichever write succeeds changes the <code>resourceVersion</code> for <code>Foo</code>.</p>
  
  <p><code>resourceVersion</code> may be used as a precondition for other operations (e.g., <code>GET</code>, <code>DELETE</code>) in the future, such as for read-after-write consistency in the presence of caching.</p>
  
  <p>"Watch" operations specify <code>resourceVersion</code> using a query parameter. It is used to specify the point at which to begin watching the specified resources.<br>
  This may be used to ensure that no mutations are missed between a <code>GET</code> of a resource (or list of resources) and a subsequent Watch, even if the current version of the resource is more recent.<br>
  This is currently the main reason that list operations (<code>GET</code> on a collection) return <code>resourceVersion</code>.</p>
</blockquote>
