Describe two more alternate numbering schemes

pep-0413.txt

@@ -710,9 +710,75 @@ of user confusion and uncertainty).
 Other Questions
 ===============
 
-Why not a date-based versioning scheme?
+Why not use the major version number?
+-------------------------------------
+
+The simplest and most logical solution would actually be to map the
+major.minor.micro version numbers to the language version, stdlib version
+and maintenance release version respectively.
+
+Instead of releasing Python 3.3.0, we would instead release Python 4.0.0
+and the release cycle would look like::
+
+    4.0.0  # Language release
+
+    4.0.1  # Maintenance release
+    4.1.0  # Standard library release
+
+    4.0.2  # Maintenance release
+    4.2.0  # Standard library release
+
+    4.0.3  # Maintenance release
+    4.3.0  # Standard library release
+    5.0.0  # Language release
+
+However, the ongoing pain of the Python 2 -> Python 3 transition (and
+associated workarounds like the ``python3`` and ``python2`` symlinks to
+refer directly to the desired release series) means that this simple option
+isn't viable for historical reasons.
+
+One way that this simple approach *could* be made to work is to merge the
+current major and minor version numbers directly into a 2-digit major
+version number::
+
+    33.0.0  # Language release
+
+    33.0.1  # Maintenance release
+    33.1.0  # Standard library release
+
+    33.0.2  # Maintenance release
+    33.2.0  # Standard library release
+
+    33.0.3  # Maintenance release
+    33.3.0  # Standard library release
+    34.0.0  # Language release
+
+
+Why not use a four part version number?
 ---------------------------------------
 
+Another simple versioning scheme would just add a "standard library" version
+into the existing versioning scheme::
+
+    3.3.0.0  # Language release
+
+    3.3.0.1  # Maintenance release
+    3.3.1.0  # Standard library release
+
+    3.3.0.2  # Maintenance release
+    3.3.2.0  # Standard library release
+
+    3.3.0.3  # Maintenance release
+    3.3.3.0  # Standard library release
+    3.4.0.0  # Language release
+
+However, this scheme isn't viable due to backwards compatibility constraints
+on the ``sys.version_info`` structure.
+
+
+Why not use a date-based versioning scheme?
+-------------------------------------------
+
 Earlier versions of this PEP proposed a date-based versioning scheme for
 the standard library. However, such a scheme made it very difficult to
 handle out-of-cycle releases to fix security issues and other critical