python-peps/pep-0226.txt

PEP: 226
Title: Python 2.1 Release Schedule
Version: $Revision$
Author: Jeremy Hylton <jeremy@digicool.com>
Status: Incomplete
Type: Informational
Created: 16-Oct-2000
Python-Version: 2.1
Post-History:

Abstract

    This document describes the post Python 2.0 development and
    release schedule.  According to this schedule, Python 2.1 will be
    released in mid-March of 2001.  The schedule primarily concerns
    itself with PEP-size items.  Small bug fixes and changes will
    occur up until the first beta release.


Tentative Release Schedule

    16-Oct-2000: Python 2.0 final release
 
    These dates represent goals, not commitments.

    16-Dec-2000: 2.1 PEPs ready for review
    01-Feb-2001: First 2.1 beta release
    16-Mar-2001: 2.1 final release


Guidelines for making changes for Python 2.1

    The guidelines and schedule will be revised based on discussion in
    the python-dev@python.org mailing list.

    The PEP system was instituted late in the Python 2.0 development
    cycle and many changes did not follow the process described in PEP
    1.  The development process for 2.1, however, will follow the PEP
    process as documented.

    The first eight weeks following 2.0 final will be the design and
    review phase.  By the end of this period, any PEP that is proposed
    for 2.1 should be ready for review.  This means that the PEP is
    written and discussion has occurred on the python-dev@python.org
    and python-list@python.org mailing lists.

    The next six weeks will be spent reviewing the PEPs and
    implementing and testing the accepted PEPs.  When this period
    stops, we will end consideration of any incomplete PEPs.  Near the
    end of this period, there will be a feature freeze where any small
    features not worthy of a PEP will not be accepted.

    Before the final release, we will have six weeks of beta testing
    and a release candidate or two.


Bug fix releases before 2.1

    We may have to issue Python 2.0.1 for critical bug fixes.  If we
    need to issue a bug fix release, we will use a CVS branch. 


General guidelines for submitting patches and making changes

    Use good sense when committing changes.  You should know what we
    mean by good sense or we wouldn't have given you commit privileges
    <0.5 wink>.  Some specific examples of good sense include:

    - Do whatever the dictator tells you.

    - Discuss any controversial changes on python-dev first.  If you
      get a lot of +1 votes and no -1 votes, make the change.  If you
      get a some -1 votes, think twice; consider asking Guido what he
      thinks.

    - If the change is to code you contributed, it probably makes
      sense for you to fix it.

    - If the change affects code someone else wrote, it probably makes
      sense to ask him or her first.

    - You can use the SourceForge (SF) Patch Manager to submit a patch
      and assign it to someone for review.

    Any significant new feature must be described in a PEP and
    approved before it is checked in.

    Any significant code addition, such as a new module or large
    patch, must include test cases for the regression test and
    documentation.  A patch should not be checked in until the tests
    and documentation are ready.

    If you fix a bug, you should write a test case that would have
    caught the bug.

    If you commit a patch from the SF Patch Manager or fix a bug from
    the Jitterbug database, be sure to reference the patch/bug number
    in the CVS log message.  Also be sure to change the status in the
    patch manager or bug database (if you have access to the bug
    database).

    It is not acceptable for any checked in code to cause the
    regression test to fail.  If a checkin causes a failure, it must
    be fixed within 24 hours or it will be backed out.

    All contributed C code must be ANSI C.  If possible check it with
    two different compilers, e.g. gcc and MSVC.

    All contributed Python code must follow Guido's Python style
    guide.  http://www.python.org/doc/essays/styleguide.html

    It is understood that any code contributed will be released under
    an Open Source license.  Do not contribute code if it can't be
    released this way.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: