<p>The <a href="https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions" rel="nofollow noreferrer">Kubernetes docs</a> state the following about the <code>metadata.resourceVersion</code> of a K8s object</p>
<blockquote>
<p>You must not assume resource versions are numeric or collatable. API clients may only compare two resource versions for equality (this means that you must not compare resource versions for greater-than or less-than relationships).</p>
</blockquote>
<p>I'm glad I read this because I was about to do exactly the thing it says not to do (comparison with <code>&gt;</code> or <code>&lt;</code> to check consistency).</p>
<p>My question is: Why not? Why are clients not allowed to do this?</p>
<p>Edits: To clarify, the resource version this question refers to is the <code>metadata.resourceVersion</code> of K8s objects, not the <code>apiVersion</code>.</p>
<p>In my experience, the resource version is an integer, increasing monotonically in time (incremented each time the resource is modified). It seems the docs say this is not a guarantee.</p>

Dmitri Gekhtman
<p>Posting this as a community wiki, feel free to edit and expand.</p>
<hr />
<p><strong>resourceVersion</strong></p>
<p>I think most correct answer will be:</p>
<blockquote>
<p>Kubernetes leverages the concept of resource versions to achieve
optimistic concurrency. All Kubernetes resources have a
&quot;resourceVersion&quot; field as part of their metadata. This
resourceVersion is a string that identifies the internal version of an
object that can be used by clients to determine when objects have
changed. 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 StatusConflict (HTTP status code 409).</p>
<p>The resourceVersion is changed by the server every time an object is
modified. If resourceVersion is included with the PUT 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 resourceVersion matches the specified value.</p>
<p>The resourceVersion is currently backed by etcd's modifiedIndex.
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 resourceVersion 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
resourceVersion is to have received it from the server in response to
a prior operation, typically a GET. This value MUST be treated as
opaque by clients and passed unmodified back to the server. Clients
should not assume that the resource version has meaning across
namespaces, different kinds of resources, or different servers.
Currently, the value of resourceVersion 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
resourceVersion 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>
</blockquote>
<p>Since there are chances that this logic can be changed, it's better to follow what kubernetes developers offer since they know further changes better than anyone else do.</p>
<p>Also in API documentation it's said that it's a <code>string</code> type, not <code>integer</code> or <code>date</code>, see <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#objectmeta-v1-meta" rel="nofollow noreferrer">here</a>.</p>
<p>Please find more details <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency" rel="nofollow noreferrer">about Concurrency Control and Consistency</a>.</p>
<hr />
<p><strong>apiVersion</strong></p>
<p>Simple and short answer - because versions are not numeric and sometimes it can be changed very significantly.</p>
<p>Below is a couple of examples that I know/used which will show the difference:</p>
<ul>
<li><p><code>ingress</code>:</p>
<p>used to be - <code>extensions/v1beta1</code></p>
<p>actual version - <code>networking.k8s.io/v1</code></p>
</li>
<li><p><code>istio</code> uses both versions at the moment:</p>
<p><code>networking.istio.io/v1alpha3</code> and <code>networking.istio.io/v1beta1</code></p>
</li>
</ul>
<p>So at this point comparison with <code>&gt;</code> or <code>&lt;</code> won't work. And much more precise method is to check whether API version is same or not.</p>
