[Python-checkins] peps: Assorted cleanups, plus a note about support for even faster stdlib release
nick.coghlan
python-checkins at python.org
Sat Feb 25 13:24:19 CET 2012
http://hg.python.org/peps/rev/f2e7ef06ce78
changeset: 4080:f2e7ef06ce78
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sat Feb 25 22:24:14 2012 +1000
summary:
Assorted cleanups, plus a note about support for even faster stdlib release cycles
files:
pep-0413.txt | 117 +++++++++++++++++++++++++++++---------
1 files changed, 88 insertions(+), 29 deletions(-)
diff --git a/pep-0413.txt b/pep-0413.txt
--- a/pep-0413.txt
+++ b/pep-0413.txt
@@ -136,7 +136,7 @@
Python level.
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:
+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
@@ -150,6 +150,7 @@
* 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::
@@ -186,7 +187,7 @@
**Status quo:** must choose between 3.3 and 2.7
-**This PEP:** must first choose between 3.3 (13.02), 3.3 (12.08) and 2.7.
+**This PEP:** must choose between 3.3 (13.02), 3.3 (12.08) and 2.7.
**PEP 407:** must choose between 3.4, 3.3 (LTS) and 2.7.
@@ -349,7 +350,7 @@
*is* an extra piece of information that users may need to pass back to
developers when reporting issues with Python libraries (or Python itself,
on our own tracker). However, by including it in ``sys.version``, many
-fault reports will already include, and it is easy to request if needed.
+fault reports will already include it, and it is easy to request if needed.
Effects
@@ -359,14 +360,15 @@
---------------------------
Similar to PEP 407, this PEP will break up the delivery of new features into
-more discrete chunks. Instead of whole raft of changes landing all at once
+more discrete chunks. Instead of a whole raft of changes landing all at once
in a language release, each language release will be limited to 6 months
worth of standard library changes, as well as any changes associated with
new syntax.
-If a release date slips by a month or two, I would keep the planned standard
-library version number rather than updating it to reflect the actual release
-date.
+If a release date slips by a month or two, the current proposal is to keep
+the planned standard library version number rather than updating it to
+reflect the actual release date.
+
Effect on workflow
------------------
@@ -385,9 +387,6 @@
should be checked in on ``3.3-compat`` and then merged to ``default``.
Otherwise it should be checked in directly to ``default``.
-The ``3.3-compat`` branch would be closed after the 3.3+13.08 release, as
-the next release at that time will be a full language release.
-
The "version added" and "version changed" markers for any changes made on
the ``3.3-compat`` branch would need to be flagged with both the language
version and the standard library version. For example: "3.3 (13.02)".
@@ -395,13 +394,33 @@
Any changes made directly on the ``default`` branch would just be flagged
with "3.4" as usual.
+The ``3.3-compat`` branch would be closed after the 3.3+13.08 release, as
+the next release at that time will be a full language release and changes
+(including standard library changes) should be marked accordingly.
+
Effect on bugfix cycle
----------------------
-The effect on the bug fix cycle is essentially the same as that on the
+The effect on the bug fix workflow is essentially the same as that on the
workflow for new features - there is one additional branch to pass through
-before the change reaches default branch.
+before the change reaches the ``default`` branch.
+
+If critical bugs are found in a maintenance release, then new maintenance and
+standard library releases will be created to resolve the problem. The micro
+release number will be incremented for both the language version and the
+standard library version.
+
+If critical bugs are found in a standard library release that do not affect
+the associated maintenance release, then only a new standard library release
+will be created and only the standard library version's micro release number
+will be incremented.
+
+Note that in these circumstances, the standard library release *may* include
+additional features, rather than just containing the bug fix. It is
+assumed that anyone that cares about receiving *only* bug fixes without any
+new features mixed in will already be relying strictly on the maintenance
+releases rather than using the new standard library releases.
Effect on the community
@@ -428,10 +447,11 @@
greatly reassure the rest of the community that no, we're not suddenly
asking them to triple their own rate of development. Instead, we're merely
going to ship standard library updates for the next language release in
-three 6-monthly installments rather than delaying them all, even those that
-are backwards compatible with the previously released version of Python.
+6-monthly installments rather than delaying them all until the next language
+definition update, even those changes that are backwards compatible with the
+previously released version of Python.
-The community benefits list in PEP 407 are equally applicable to this PEP,
+The community benefits listed in PEP 407 are equally applicable to this PEP,
at least as far as the standard library is concerned:
People who value reactivity and access to new features (without taking the
@@ -455,9 +475,20 @@
-----------
The "What's New" documents would be split out into separate documents for
-standard library releases and language releases. If the major version
-number only continues to increase once every decade or so, resolving the
-eventual numbering conflict can be safely deemed somebody elses problem :)
+standard library releases and language releases. So, during the 3.3 release
+cycle, we would see:
+
+* What's New in Python 3.3?
+* What's New in Python 3.3 (13.02)?
+* What's New in Python 3.3 (13.08)?
+
+And the finally, we would see the next language release:
+
+* What's New in Python 3.4?
+
+For the benefit of users that ignore standard library releases, the 3.4
+What's New would link back to the What's New documents for each of the
+standard library releases in the 3.3 series.
NEWS
@@ -465,15 +496,15 @@
Merge conflicts on the NEWS file are already a hassle. Since this PEP
proposes introduction of an additional branch into the normal workflow,
-resolving this becomes even more critical. While Mercurial phases will
+resolving this becomes even more critical. While Mercurial phases may
help to some degree, it would be good to eliminate the problem entirely.
One suggestion from Barry Warsaw is to adopt a non-conflicting
separate-files-per-change approach, similar to that used by Twisted [2_].
-For this PEP, one possible layout for such an approach (adopted following
-the release of 3.3.0+12.8.0 using the existing NEWS process) might look
-like::
+For this PEP, one possible layout for such an approach (to be adopted
+following the initial release of 3.3.0+12.8.0 that will use the current NEWS
+process) might look like::
Misc/
news_entries/
@@ -489,7 +520,7 @@
tests/
<files for testing changes>
3.4.0/ # default branch changes
- language/
+ language/ # Only exists for "x.y.0"
<files for core language changes>
builtins/
<files for builtin changes>
@@ -519,6 +550,10 @@
history), but does make it easier for *humans* to keep the different versions
in order.
+Other layouts are obviously also possible (for example, having separate "3.3"
+and "3.4" directories to group entries for each language version and the
+associated maintenance and standard library releases).
+
Option: Slowing down the language release cycle
===============================================
@@ -565,6 +600,27 @@
then be available every 6 months after that.
+Future: 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
+release cycle. The standard library could be updated every 3 months, or
+even once a month, without having any flow on effects on the language
+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?
+
+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.
+
+
Why isn't PEP 384 enough?
=========================
@@ -586,14 +642,17 @@
===================================================
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 finish). You
-can't create a standalone pure Python standard library, because too many
-"modules" are actually tightly linked in to the internal details of the
-respective interpreters (e.g. ``weakref``, ``gc``, ``sys``).
+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``).
Creating a separate development branch that is kept compatible with the
-previous feature release should provide most of the benefits of a
-separate standard library repository with only a fraction of the pain.
+previous feature release, and making releases from that branch that are
+flagged with a separate date-based version number should provide most of
+the benefits of a separate standard library repository with only a fraction
+of the pain.
Acknowledgements
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list