[Python-Dev] Rules of a beta release?

[Guido van Rossum]

> Now that we are officially in a beta release, I want to clarify what
> the ground rules are in terms of commits are.  Obviously no new
> functionality such as new modules or built-ins.  But what about
> small features?  Specifically, since I have CVS commit I can finally
> apply my patch to regrtest.py to allow the use of a skips.txt file
> listing tests to skip (unless people don't want it anymore).  Now
> that is a new feature, but it is minor *and* it is on an
> undocumented module (for now; I will get those docs done before 2.3
> final is reached).

IMO in general fiddling with the test suite during beta is okay.

There should be guidelines for this (for all I know there's already a
PEP :-) but I'm too tired to write any more about it.  Use common
sense.  It should be the case that if someone tested their application
with 2.3b1 and they tweaked everything to work with that version, they
shouldn't have to tweak anything to work with 2.3final.

I plan to make an exception for IDLE: a brand new copy of IDLEfork
will replace the current IDLE 0.8.  I was very tempted to include it
today, but there wasn't time to get all the loose ends tied up: it has
a C extension now, and the Windows installer would have to be
changed; plus, Kurt has some improvements that he hasn't even checked
in.  So he'll do an independent IDLEfork beta, and then it'll be
incorporated into Python.  Hopefully that will all be done two weeks
from now.

> Is this reasonable to commit now?  Anything else I should know so I
> don't run a muck in CVS?  =)

Don't be too fearful -- if you really commit an atrocity, the nice
thing of CVS is that it's easy to roll back. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)