Create Branch for Release

Update Release Values

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.

Commit Release

Look at the log messages in commit.txt and create log.file that hits the highlights of the changes that have been incorporated. Much of the information should already be in src/Announce.txt, so it mostly involves copy-n-past from there. Cut it heavily to one or two lines per feature; the major use of this log is people who are scanning to see where a feature was added, and they will appreciate clarity and brevity. This is an example of what log.file might be like:

Rebased the release branch to r54321 of the checkpoint branch.
-- The blah was updated to do foo
-- Feature bar was added by John Doe
-- Various typos

Commit the changes using the log message:

$ hg ci -l log.file

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 VERSION=$VERSION

Test the Candidate Packages

This script is kept in the distribution as bin/xxxxxxxxx:

$ set -e
$ python runtest.py -a

Make a copy of it and edit it based on the description below.

Regression Test

The first line of the script runs the regression test. The SCons BuildBot monitors this branch and probably started running regression tests as soon as you checked in the branch. If so, delete the first line of the script as the Build``Bot is more comprehensive that running the test on a single machine. You will need to keep an eye on the BuildBot display until all the slaves have finished.

Package Tests

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.

Click on Project Admin -> File Manager
Open the scons, scons-src, and scons-local directories. Within each one, open the $VERSION folder. In the scons/$VERSION directory, select the RELEASE.txt file and mark mark it as the release notes in the popup that appears, then save.

If this is a final release of the production branch, select scons-$VERSION.win32.exe and mark it as the default selection for Windows, then select scons-$VERSION.tar.gz and mark it as the default for all other OSes.

In turn, select each of the files (other than the release notes file itself, which is automatically set) in all three folders (and the folders themselves) and specify that RELEASE.txt is to be the release note for that file. Because of the way the page refreshes after clicking Save, it seems to be easier to start at the bottom and work your way up.

FIXME: TEST THIS: You can do multiple releases quickly by opening the File Manager page multiple times in a separate tabs, but if you do, make sure to wait for the page to reload completely in one tab before clicking Save in another. Trying to update multiple releases at once doesn't work, presumably because the session can only handle one update at a time.

Hide previous releases

For a checkpoint release, hide all checkpoints in the same series that are older than this checkpoint.

For a minor or micro release, hide all the checkpoint releases leading up to this release.

For a major release, hide all the checkpoint releases leading up this release AND hide all major and minor releases older than this release.
For each release name you wish to hide, you have to do the following in scons, scons-local, and scons-src:

Click on the gear icon to the left of the package name and select Cut from the popup.

Click on the gear icon to the left of old checkpoints and select Paste from the popup.
Test downloading

Navigate to the SCons download page. If you're reading this from a printed copy rather than the wiki page and can't click on the link, follow these instructions:

FIXME Add instructions if can't click.
For each of the scons, scons-src, and scons-local directories:

Open the directory.

Open the $VERSION folder within the directory.

For each package in the folder, click on the link to download it.

Verify that the files arrived and look reasonable.
Add news item

Navigate to the Project News page. If you're reading this from a printed copy rather than the wiki page and can't click on the link, follow these instructions:

Update Trunk to Next Version

From within the trunk directory, edit ReleaseConfig and change the assignment of release_level to 'post'.

$ 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.

A release level of 'post' causes update-release-info.py to update ReleaseConfig itself to the next minor version and then tweak some other files to set them up for the the beginning of a new version.