Non-Tip Alpha Release
An alpha release is a quick-n-dirty way of getting out initial releases for testing. It can be done at any point, even from a read-only tree, as there's no requirement for committing the branch when the process is completed.
If you want a checklist you can mark off as you go, cut-n-paste these contents.
These initializations are the conventions that will be used in the rest of this flow.
The location of the SCons SVN archive:
$ export HG=https://bitbucket.org/scons/scons
The version string, which should look something like this:
Check Out Branch
From within your base directory, execute this command:
$ svn co $SVN/branches/3.2.x working $ cd working
Update Release Values
Verify that the release_level variable in ReleaseConfig is being set to 'alpha'.
$ python bin/update-release-info.py release
The ReleaseConfig file is where the "official" version number ($VERSION), the Python version floors, and other information about the release is recorded. This command takes the information in ReleaseConfig and inserts it in the necessary files.
Run Regression Tests (Optional)
Since an alpha package is intended to be transient, only useful for a short time, running the regression tests may not be necessary.
To run the tests, simply execute this command:
$ python runtest.py -a
Build Candidate Packages
Provided you have all of the necessary utilities installed, this should be a simple matter of:
$ rm -rf build $ python bootstrap.py
Test Candidate Packages (Optional)
Since an alpha package is intended to be transient, only useful for a short time, testing the packages may not be necessary.
The build step above not only builds the packages but also unpacks all of them into subdirectories so that you can run the test suite against the packaged goods. This is intended to catch packaging problems such as not adding a new module to the packaging MANIFEST list(s). The runtest.py script supports a -p option and arguments that run the SCons tests against the different unpacked directories.
Edit the script to include the tests you want to include. If you want to be complete, test all of the packages.
To be quicker but still reasonably thorough, test tar-gz and zip, one each of local- and src- (probably do -tar-gz for one and -zip for the other), and rpm.
For a quick-n-dirty test, just test tar-gz or zip, and maybe rpm. Since all of the different packages use the same lists as input, it's pretty unlikely that the tests will pass on one package and fail for another.
TO BE ADDED LATER; if you have some good words for this topic, please edit ReleaseHOWTO/NonTipAlphaBody and put them in.