An alpha release is published from the trunk. It can be done at any point, even from a read-only tree, as there's no requirement for committing trunk when the process is completed.
An alpha release has a very short lifetime; in general, it exists long enough to do some testing and then it is thrown away. These steps are suggestive, not prescriptive; individual cases may choose among the steps (and even add new ones) to perform their tasks.
For example, the standard BuildBot run skips the steps after the regression tests, while the packaging run skips the regression tests and instead does the tests of the candidate packages. In both cases, the alpha release is immediately discarded.
Another example might be automatically publishing the packages every day; to keep the run-time reasonable, the testing steps would be skipped.
BLAH BLAH BLAH
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:
BLAH BLAH BLAH
Check Out Trunk
From within your base directory, execute this command:
$ svn co $SVN/trunk
Update Release Values
From within the trunk directory:
$ 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 FIXME and put them in.