[Python-Dev] Rules of a beta release? (original) (raw)

Guido van Rossum guido@python.org
Fri, 25 Apr 2003 20:19:14 -0400

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/)