Here are some steps for making a new release of pygame. So everyone knows what needs to be done to make a release work smoothly. == release steps == * declare next release as coming soon to developers, and mailing list. * declare feature freeze. * check with people on different platforms that tests are working. * ask platform people to sign off for their platform building, and testing ok. * WHATSNEW document is updated, with any changes. * declare tar ball set, by making a branch in hg with the pygame version as rc1. eg 1.7.1rc1 - files to change version string: lib/version.py setup.py readme.html readme.rst - This is the hg command used: TODO. * second round of testing goes on the new release branch. If any changes need to be made, all platforms need to be tested again and signed off. The pygame rc version is incremented and a new rc tar ball is released. eg 1.7.1rc2. * if no changes needed to be made to the rc release, then the version is changed. eg from 1.7.1rc1 to 1.7.1release * release person uploads final sources tarball to website. * documentation is remade, and uploaded to website, not before sources. * release binaries, not before sources. * announce to the mailing list, and the world that a new pygame is released. * the version of pygame is incremented by 1 and pre appended. eg 1.7.1 goes to 1.7.2pre == Some definitions and explanations. == release person := person who is in charge of doing release. Should be one person. platform people := people responsible for each platform. eg macosx, windows, linux, freebsd etc. testing pygame := at least all the examples run ok. Also test major pygames, solarwolf, and pyddr work. Try to run other gamelets, and games that you know of. Try to test with different parts installed/uninstalled etc. rc releases := these are release candidates. If no changes need to be made, then the pygame version is changed and it can be released. pre releases := these are snap shots from hg.