Add versioning section to "future API standard evolution"

Author: rgommers

spec/future_API_evolution.md

@@ -10,4 +10,30 @@
 
 ## Versioning
 
-
+This API standard uses the following versioning scheme:
+
+- The version is date-based, in the form `yyyy.mm` (e.g., `2020.12`).
+- The version shall not include a standard way to do `alpha`/`beta`/`rc` or
+  `.post`/`.dev` type versions.
+  _Rationale: that's for Python packages, not for a standard._
+- The version must be made available at runtime via an attribute
+  `__array_api_version__` by a compliant implementation, in `'yyyy.mm'` format
+  as a string, in the namespace that implements the API standard.
+  _Rationale: dunder version strings are the standard way of doing this._
+
+No utilities for dealing with version comparisons need to be provided; given
+the format simple string comparisons with Python operators (`=-`, `<`, `>=`,
+etc.) will be enough.
+
+.. note::
+
+    Rationale for the `yyyy.mm` versioning scheme choice:
+    the API will be provided as part of a library, which already has a versioning
+    scheme (typically PEP 440 compliant and in the form `major.minor.bugfix`),
+    and a way to access it via `module.__version__`. The API standard version is
+    completely independent from the package version. Given the standardization
+    process, it resembles a C/C++ versioning scheme (e.g. `C99`, `C++14`) more
+    than Python package versioning.
+
+The frequency of releasing a new version of an API standard will likely be at
+regular intervals and on the order of one year, however no assumption on frequency of new versions appearing must be made.