Explain feature freeze.

Mention IDLE.
This commit is contained in:
Guido van Rossum 2003-02-19 19:36:27 +00:00
parent 247c1e1073
commit 1d9e85d7a2
1 changed files with 7 additions and 5 deletions

View File

@ -12,8 +12,8 @@ Abstract
This document describes the development and release schedule for This document describes the development and release schedule for
Python 2.3. The schedule primarily concerns itself with PEP-sized Python 2.3. The schedule primarily concerns itself with PEP-sized
items. Small features may be added until the first beta release. items. Small features may be added up to and including the first
Bugs may be fixed until the final release. beta release. Bugs may be fixed until the final release.
There will be at least two alpha releases, two beta releases, and There will be at least two alpha releases, two beta releases, and
one release candidate. Alpha and beta releases will be spaced at one release candidate. Alpha and beta releases will be spaced at
@ -22,11 +22,10 @@ Abstract
release does not count). Release candidates will be spaced at release does not count). Release candidates will be spaced at
least one week apart (excepting again blunder corrections). least one week apart (excepting again blunder corrections).
Based on the first alpha release, which was made on Dec. 31, 2002, Here's a tentative release schedule that follows the above
here's a fairly aggressive release schedule that follows the above
guidelines: guidelines:
alpha 2 -- mid February alpha 2 -- February 19, 2003
beta 1 -- late March beta 1 -- late March
beta 2 -- late April beta 2 -- late April
rc 1 -- late May rc 1 -- late May
@ -150,6 +149,9 @@ Planned features for 2.3
feedback to python-dev@python.org; I hope to maintain this for the feedback to python-dev@python.org; I hope to maintain this for the
life of the 2.3 development process. life of the 2.3 development process.
- I plan to integrate the new version of IDLE from the IDLEfork
project (http://idlefork.sf.net).
- We need a new PyArg_Parse*() format code that returns an - We need a new PyArg_Parse*() format code that returns an
unsigned C long int that receives the lower LONG_BIT bits of the unsigned C long int that receives the lower LONG_BIT bits of the
Python argument, truncating without range checking. (SF Python argument, truncating without range checking. (SF