[Python-checkins] peps: Describe two more alternate numbering schemes

[nick.coghlan]

http://hg.python.org/peps/rev/a2ad0f016166
changeset:   4086:a2ad0f016166
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Feb 26 15:33:31 2012 +1000
summary:
  Describe two more alternate numbering schemes

files:
  pep-0413.txt |  68 +++++++++++++++++++++++++++++++++++++++-
  1 files changed, 67 insertions(+), 1 deletions(-)


diff --git a/pep-0413.txt b/pep-0413.txt
--- a/pep-0413.txt
+++ b/pep-0413.txt
@@ -710,9 +710,75 @@
 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

-- 
Repository URL: http://hg.python.org/peps