Non-Tip Beta Release
A beta release is prepared and published when the branch has stabilized enough that it's worth exposing to a wider audience.
If you want a checklist you can mark off as you go, cut-n-paste these contents.
- Assumed Setup
- Check Out Branch
- Edit Configuration Files
- Update Release Values
- Confirm Users' Guide is OK
- Commit Branch
- Run Regression Tests
- Build Candidate Packages
- Test Candidate Packages
- Tag the Release
- Archive Candidate Packages
- Update SourceForge
- Update scons.org
- Update the scons.org Web Site
- Update Tigris.org
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
Edit Configuration Files
Update Release Values
Verify that the release_level variable in ReleaseConfig is being set to 'beta'.
$ 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.
Confirm Users' Guide is OK
CAUTION: Only try this step if you have the toolchain for building the documentation. The packages needed are discussed in DeveloperGuide/Documentation. It's quite a list.
The following steps verify that the user guide sources (some of which are generated from other files) are up to date.
FIXME (This will probably be reworked to be part of the build step.)
$ python bin/scons-doc.py --diff $ python bin/scons-doc.py --update
Create log.file ... FIXME
$ svn commit -F log.file Sending some/file Sending some/other/file Transmitting file data .. Committed revision 54321. $
Run Regression Tests
The SCons BuildBot will usually be monitoring this branch, so all you have to do is wait until the BuildBot display for the commit from the previous step shows that all the regression tests have been run. On the other hand, if you're feeling bored, you can run the regression tests while you're waiting...
To run the tests, simply execute this command:
$ python runtest.py -a
If the regression tests fail, fix the problem in the branch following your usual development practices and start the flow again.
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
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.
If any of the candidate packages fail, fix the problem in the branch following your usual development practices and start the flow again.
Tag the Release
Verify that you have SVN and VERSION in your shell environment as described in the setup section above, then run this command:
$ svn cp . $SVN/tags/$VERSION -m"Tagging $VERSION"
Archive Candidate Packages
Verify that you have SVN and VERSION in your shell environment as described in the setup section above, then run the bin/FillMeIn script:
set -e # stop on error rm -rf ARCHIVE svn co --depth=files $SVN/ARCHIVE mkdir ARCHIVE/scons-$VERSION cp build/dist/* ARCHIVE/scons-$VERSION svn add ARCHIVE/scons-$VERSION svn commit -m"Saving copy of $VERSION in archive" ARCHIVE rm -rf ARCHIVE
Verify that you have SVN and VERSION in your shell environment as described in the setup section above, then run the bin/scp-sourceforge script:
$ sh bin/scp-sourceforge sf_username
Mark packages with release notes
Navigate to the SourceForge File Manager page for SCons. If you're reading this from a printed copy rather than the wiki page and can't click on the link, follow these instructions:
Log in to your SourceForge account
Click on Develop just under Forge in the SourceForge banner.
Under My Projects, click on Develop next to the SCons project.
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.
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:
FIXME These aren't complete.
Go to the Project Admin -> Feature Settings page
In Project News, click Submit.
Once you get to the Project News page:
Fill in the Subject: box with something like "Release $VERSION now available"
Cut-and-paste the blurb you prepared above into the Details: box
Update the scons.org Web Site
Apply changes to web site
Commit the changes you prepared above:
$ svn commit -m"Changes to publish the SCons $VERSION release"
Now you have to go update the site:
$ ssh -l scons manam.pair.com $ cd public_html $ cp -al production new # hard-link the whole tree; fast. $ (cd new && svn up) # should be fast here too $ rm -rf previous $ mv production previous && mv new production $ exit
Now point your browser to the SCons home page. If anything is amiss, fix it, commit the necessary changes, and update the site.
Navigate to the SCons download page.
- Verify that the opening paragraph makes sense.
- In the right-hand sidebar, find the download section corresponding to $VERSION.
- For each file in the section, click on the link to download it.
- Verify that the files arrived and look reasonable.
Update project pages
Send the changes you prepared above to Tigris:
From within the www subdirectory of your trunk directory:
$ svn commit -m"Update project web pages for $VERSION"
Point your browser at the roadmap page; if anything's amiss, fix it and commit again.
Add news item
Log in to your tigris.org account
Click Announcements in the left-hand nav bar
Click Add new announcement
- Double-check the date (it's probably already set)
Fill in the Headline box
Fill in the Body box with the HTML blurb
Click Add new announcement
Add release name to issue tracker
Click Issue Tracker on the left-hand nav bar
Click Configuration options
Click Add/edit components
Under scons, to the far right of Add ..., click Version
At the bottom of the list, to the right of "Add a new version", click Add
Fill in the Version: box with the release ($VERSION)
Click the Add button