[Python-checkins] peps: Further refinements to PEP 413, save state before changing the proposed stdlib
nick.coghlan
python-checkins at python.org
Sun Feb 26 03:49:59 CET 2012
http://hg.python.org/peps/rev/a2ad67fa36f8
changeset: 4084:a2ad67fa36f8
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sun Feb 26 12:49:49 2012 +1000
summary:
Further refinements to PEP 413, save state before changing the proposed stdlib versioning scheme
files:
pep-0413.txt | 241 +++++++++++++++++++++++++++-----------
1 files changed, 172 insertions(+), 69 deletions(-)
diff --git a/pep-0413.txt b/pep-0413.txt
--- a/pep-0413.txt
+++ b/pep-0413.txt
@@ -99,37 +99,67 @@
Proposal
========
-This PEP proposes the addition of a new ``sys.stdlib_info`` attribute that
-records a date based standard library version above and beyond the underlying
-interpreter version::
+This PEP proposes the introduction of a new kind of CPython release:
+"standard library releases". As with PEP 407, this will give CPython 3 kinds
+of release:
- sys.stdlib_info(year=2012, month=8, micro=0, releaselevel='final', serial=0)
+* Language release: "x.y.0"
+* Maintenance release: "x.y.z" (where z > 0)
+* Standard library release: "x.y (YY.MM)"
-This information would also be included in the ``sys.version`` string::
+Under this scheme, an unqualified version reference (such as "3.3") would
+always refer to the most recent corresponding language or maintenance
+release. It will never be used without qualification to refer to a standard
+library release (at least by python-dev - obviously, we can only set an
+example, not force the rest of the Python ecosystem to go along with it).
- Python 3.3.0 (12.08.0, default:c1a07c8092f7+, Feb 17 2012, 23:03:41)
- [GCC 4.6.1]
+Language releases will continue as they are now, as new versions of the
+Python language definition, along with a new version of the CPython
+interpreter and the Python standard library. Accordingly, a language
+release may contain any and all of the following changes:
+
+* new language syntax
+* new standard library changes (see below)
+* new deprecation warnings
+* removal of previously deprecated features
+* changes to the emitted bytecode
+* changes to the AST
+* any other significant changes to the compilation toolchain
+* changes to the core interpreter eval loop
+* changes to the C ABI (although the PEP 384 stable ABI must be preserved)
+* bug fixes
+
+Maintenance releases will also continue as they do today, being strictly
+limited to bug fixes for the corresponding language release. No new features
+or radical internal changes are permitted.
+
+The new standard library releases will occur in parallel with each
+maintenance release and will be qualified with a date-based version
+identifier documenting their *actual* release date. Standard library
+releases may include the following changes:
+
+* new features in pure Python modules
+* new features in C extension modules (subject to PEP 399 compatibility
+ requirements)
+* new features in language builtins (provided the C ABI remains unaffected)
+* bug fixes from the corresponding maintenance release
+
+
+Release Cycle
+-------------
When maintenance releases are created, *two* new versions of Python would
actually be published on python.org (using the first 3.3 maintenance release,
planned for February 2013 as an example)::
- 3.3.1 + 12.08.1 # Maintenance release
- 3.3.1 + 13.02.0 # Standard library release
-
-A standard library release would just be the corresponding maintenance
-release, with the following additional, backwards compatible changes:
-
-* new features in pure Python modules
-* new features in C extension modules (subject to PEP 399 compatibility
- requirements)
-* new features in language builtins (provided the C ABI remains unaffected)
+ 3.3.1 # Maintenance release
+ 3.3 (13.02) # Standard library release
A further 6 months later, the next 3.3 maintenance release would again be
accompanied by a new standard library release::
- 3.3.2 + 12.08.2 # Maintenance release
- 3.3.2 + 13.08.1 # Standard library release
+ 3.3.2 # Maintenance release
+ 3.3 (13.08) # Standard library release
Again, the standard library release would be binary compatible with the
previous language release, merely offering additional features at the
@@ -138,30 +168,62 @@
Finally, 18 months after the release of 3.3, a new language release would
be made around the same time as the final 3.3 maintenance release::
- 3.3.3 + 12.08.3 # Maintenance release
- 3.4.0 + 14.02.0 # Language release
+ 3.3.3 # Maintenance release
+ 3.4.0 # Language release
Language releases would then contain all the features that are not
permitted in standard library releases:
-* new language syntax
-* new deprecation warnings
-* removal of previously deprecated features
-* changes to the emitted bytecode
-* changes to the AST
-* any other significant changes to the compilation toolchain
-* changes to the core eval loop
-* changes to the C ABI
-
The 3.4 release cycle would then follow a similar pattern to that for 3.3::
- 3.4.1 + 14.02.1 # Maintenance release
- 3.4.1 + 14.08.0 # Standard library release
- 3.4.2 + 14.02.2 # Maintenance release
- 3.4.2 + 15.02.0 # Standard library release
- 3.4.3 + 14.02.3 # Maintenance release
- 3.5.0 + 15.08.0 # Language release
+ 3.4.1 # Maintenance release
+ 3.4 (14.08) # Standard library release
+ 3.4.2 # Maintenance release
+ 3.4 (15.02) # Standard library release
+
+ 3.4.3 # Maintenance release
+ 3.5 # Language release
+
+
+Programmatic Version Identification
+-----------------------------------
+
+To expose the new release details programmatically, this PEP proposes the
+addition of a new ``sys.stdlib_info`` attribute that records the date based
+standard library version above and beyond the underlying interpreter
+version. Using the initial Python 3.3 release as an example::
+
+ sys.stdlib_info(year=2012, month=8, micro=0, releaselevel='final', serial=0)
+
+This information would also be included in the ``sys.version`` string::
+
+ Python 3.3.0 (12.08.0, default, Feb 17 2012, 23:03:41)
+ [GCC 4.6.1]
+
+
+Security Fixes and Other "Out of Cycle" Releases
+------------------------------------------------
+
+For maintenance releases the process of handling out-of-cycle releases (for
+example, to fix a security issue or resolve a critical bug in a new release),
+remains the same as it is now: the minor version number is incremented and a
+new release is made incorporating the required bug fixes, as well as any
+other bug fixes that have been committed since the previous release.
+
+For standard library releases, things are slightly more complicated, as the
+corresponding source control branch may contain new features in addition to
+bug fixes. If such features exist, then, to provide a comprehensible release,
+it would be necessary to:
+
+1. Change the release version number to the date of the current month.
+2. Update the What's New, NEWS and documentation to refer to the new release
+ number.
+3. Make the new release.
+
+(Note: due to this problem with out-of-cycle releases, I'm considering an
+alternate standard library version scheme that would use date independent
+numbers like "33.1" and "33.2". See `Why a date-based versioning scheme?`_).
User Scenarios
==============
@@ -187,12 +249,12 @@
**Status quo:** must choose between 3.3 and 2.7
-**This PEP:** must choose between 3.3 (13.02), 3.3 (12.08) and 2.7.
+**This PEP:** must choose between 3.3 (13.02), 3.3 and 2.7.
**PEP 407:** must choose between 3.4, 3.3 (LTS) and 2.7.
**Verdict:** explaining the meaning of a Long Term Support release is about as
-complicated as explaining the meaning of the proposed standard library
+complicated as explaining the meaning of the proposed standard library release
version numbers. I call this a tie.
@@ -555,12 +617,16 @@
associated maintenance and standard library releases).
-Option: Slowing down the language release cycle
-===============================================
+Other benefits of reduced version coupling
+==========================================
+
+Slowing down the language release cycle
+---------------------------------------
The current release cycle is a compromise between the desire for stability
in the core language definition and C extension ABI, and the desire to get
-new feature (most notably standard library updates) into users hands quickly.
+new features (most notably standard library updates) into user's hands more
+quickly.
With the standard library release cycle decoupled (to some degree) from that
of the core language definition, it provides an opportunity to actually
@@ -574,34 +640,35 @@
as standard library releases become more frequent.
As simple example, if a full two years was allowed between 3.3 and 3.4,
-the 3.3 release cycle would be up looking like::
+the 3.3 release cycle would end up looking like::
- 3.2.4 # Maintenance release
- 3.3.0 + 12.08.0 # Language release
+ 3.2.4 # Maintenance release
+ 3.3.0 # Language release
- 3.3.1 + 12.08.1 # Maintenance release
- 3.3.1 + 13.02.0 # Standard library release
+ 3.3.1 # Maintenance release
+ 3.3 (13.02) # Standard library release
- 3.3.2 + 12.08.2 # Maintenance release
- 3.3.2 + 13.08.1 # Standard library release
+ 3.3.2 # Maintenance release
+ 3.3 (13.08) # Standard library release
- 3.3.3 + 12.08.3 # Maintenance release
- 3.3.3 + 14.02.1 # Standard library release
+ 3.3.3 # Maintenance release
+ 3.3 (14.02) # Standard library release
- 3.3.4 + 12.08.4 # Maintenance release
- 3.4.0 + 14.08.0 # Language release
+ 3.3.4 # Maintenance release
+ 3.4.0 # Language release
The elegance of the proposed NEWS entry layout is that this decision
wouldn't need to be made until after the 13.08 standard library release. At
that point, the ``3.3-compat`` branch could be kept open (thus adding
another standard library release to the cycle), or else it could be closed,
-committing to the next release being a full language release. The choice
-between another standard library release or a full language release would
-then be available every 6 months after that.
+committing to the next release being a full language release. If the
+compatibility branch was kept open, the choice between another standard
+library release or a full language release would then be available every
+6 months after that.
-Future: Further increasing the pace of standard library development
-===================================================================
+Further increasing the pace of standard library development
+-----------------------------------------------------------
A further benefit of the scheme proposed in this PEP is that it almost
*fully* decouples the language release cycle from the standard library
@@ -610,19 +677,55 @@
version numbering or the perceived stability of the core language.
While that pace of development isn't practical as long as the binary
-installer creation for Windows and Mac OS X involves several manual steps and
-for as long as we don't have separate "<branch>-release" trees that only
-receive versions that have been marked as good by the stable buildbots,
-it's a useful criterion to keep in mind: what if we want to make standard
-library releases even *faster* than every 6 months?
+installer creation for Windows and Mac OS X involves several manual steps
+(including manual testing) and for as long as we don't have separate
+"<branch>-release" trees that only receive versions that have been marked as
+good by the stable buildbots, it's a useful criterion to keep in mind when
+considering proposed new versioning schemes: what if we eventually want
+to make standard library releases even *faster* than every 6 months?
If the practical issues were ever resolved, then the separate date-based
versioning scheme in this PEP could handle it. The approach proposed in
-PEP 407 could not.
+PEP 407 could not (at least, not without a lot of user confusion).
+
+
+Other Questions
+===============
+
+Why a date-based versioning scheme?
+-----------------------------------
+
+While a date-based scheme does mean additional work in the case of an
+out-of-cycle release, it's an easy way to come up with a numbering system
+that is clearly orthogonal to the existing versioning scheme used for
+language releases.
+
+Another possibility would just be ``major.minor`` versioning where:
+
+* major: xy from the corresponding language release (that is, "33" for 3.3)
+* minor: release sequence number for the standard library releases
+
+Then the Python 3.3 release series would look like::
+
+ 3.3.0 # Language release
+
+ 3.3.1 # Maintenance release
+ 3.3 (33.1) # Standard library release
+
+ 3.3.2 # Maintenance release
+ 3.3 (33.2) # Standard library release
+
+ 3.3.3 # Maintenance release
+ 3.4.0 # Language release
+
+Such a scheme would have the advantage of tolerating out-of-cycle releases
+without needing to adjust the version numbering for the release, but would
+lose the minor benefit of providing clearer age information within the
+versioning scheme itself.
Why isn't PEP 384 enough?
-=========================
+-------------------------
PEP 384 introduced the notion of a "Stable ABI" for CPython, a limited
subset of the full C ABI that is guaranteed to remain stable. Extensions
@@ -639,14 +742,14 @@
Why not separate out the standard library entirely?
-===================================================
+---------------------------------------------------
Because it's a lot of work for next to no pay-off. CPython without the
standard library is useless (the build chain won't even run, let alone the
-test suite). You can't create a standalone pure Python standard library,
-because too many "modules" are actually tightly linked in to the internal
-details of their respective interpreters (e.g. ``weakref``, ``gc``, ``sys``,
-``inspect``, ``ast``).
+test suite). You can't create a standalone pure Python standard library
+either, because too many "modules" are actually tightly linked in to the
+internal details of their respective interpreters (e.g. ``weakref``, ``gc``,
+``sys``, ``inspect``, ``ast``).
Creating a separate development branch that is kept compatible with the
previous feature release, and making releases from that branch that are
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list