python-peps/pep-0361.txt

140 lines
3.6 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

PEP: 361
Title: Python 2.6 Release Schedule
Version: $Revision$
Last-Modified: $Date$
Author: Neal Norwitz
Status: Draft
Type: Informational
Created: 29-June-2006
Python-Version: 2.6
Post-History:
Abstract
This document describes the development and release schedule for
Python 2.6. The schedule primarily concerns itself with PEP-sized
items. Small features may be added up to and including the first
beta release. Bugs may be fixed until the final release.
There will be at least two alpha releases, two beta releases, and
one release candidate. The release date is planned to be in XXX 2008.
Release Manager and Crew
XXX volunteered to be Release Manager.
XXX is building the Windows installers,
XXX is building the Mac installers,
XXX the doc packages and
XXX the RPMs.
Release Schedule
Note that this schedule is completely tentative. The number of alphas,
betas and release candidates will be determined as the release process
unfolds. The minimal schedule is:
June 2007: (re)confirm the crew and start deciding on schedule.
The initial 2.6 target is for April 2008.
alpha 1: T - 16 weeks [planned]
alpha 2: T - 13 weeks [planned]
beta 1: T - 9 weeks [planned]
beta 2: T - 5 weeks [planned]
rc 1: T - 1 week [planned]
final: T [planned]
Completed features for 2.6
PEPs:
None
New modules in the standard library:
None
Other major features:
None
Possible features for 2.6
New features *should* be implemented prior to alpha2, particularly
any C modifications or behavioral changes. New features *must* be
implemented prior to beta1 or will require Release Manager approval.
The following PEPs are being worked on for possible inclusion in 2.6:
- PEP 275: Switching on Multiple Values
- PEP 297: Support for System Upgrades
Each non-trivial feature listed here that is not a PEP must be
discussed on python-dev. Other enhancements include:
- distutils replacement (requires a PEP)
- turtle.py replacement or enhancements
- adding a __dir__() magic method to control dir() [1]
New modules in the standard library:
- winerror
http://python.org/sf/1505257
(Owner: MAL)
- Check the various bits of code in Demo/ and Tools/ all still work,
update or remove the ones that don't.
- All modules in Modules/ should be updated to be ssize_t clean.
- All of Python (including Modules/) should compile cleanly with g++
- Start removing deprecated features and generally moving towards Py3k
- Replace all old style tests (operate on import) with unittest or docttest
- All tests for all untested modules
- Document undocumented modules/features
Deferred until 2.7
None
Open issues
How should import warnings be handled?
http://mail.python.org/pipermail/python-dev/2006-June/066345.html
http://python.org/sf/1515609
http://python.org/sf/1515361
How should -m (and __main__ in general) work with relative imports?
http://mail.python.org/pipermail/python-dev/2006-June/066161.html
(also see the section on main modules in PEP 338)
References
[1] Adding a __dir__() magic method
http://mail.python.org/pipermail/python-dev/2006-July/067139.html
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End: