Make sure you have a clean, up-to-date local copy without any local modifications (ant update).

Run ant release to generate the release files and create a tag in the repository (use ant release-beta or ant release-stable instead, if necessary). This will run the tests in order to double-check that there is really nothing wrong with the current code. Note that, to help identify the application's origin, the jar file will include your user name in its manifest.

You may want to verify that the program runs and behaves as expected.

Connect to your personal space on the SourceForge FTP server and upload the files. The FTP URL includes your user name: for example, https://frs.sourceforge.net/s/so/someuser/uploads. In OS X, you can do this in Finder using the "Connect to Server" command. When releasing DrJava, the following files should be uploaded:

Note that the javadocs should not be included in the file release (they will be posted on the Web site later). While waiting for files to copy, you may want to assemble the release notes (see below).

Go to the SourceForge project page and, after making sure you are logged in, go to "Admin", then "File Releases". Click "Add Release" next to the appropriate package.

Set the release name to the version tag (which is the name of the .jar file).

Insert the Release Notes and Change Log, check "Preserve my preformatted text," and click "Submit/Refresh." The Release Notes is typically a one- or two-paragraph summary of the important changes since the last release of the same type (e.g., stable releases should summarize all changes since the last stable). The Change Log, on the other hand, is an itemized list of all significant user-visible changes. You may want to look at some older notes to help preserve a consistent style. The best way to put together these notes is by consulting the Subversion logs, either via svn log or by clicking on a directory's version number in the browsable source tree. Note that Subversion has an annoying habit of not wrapping lines when change logs are displayed. As a result, you must manually insert line breaks, keeping the lines relatively short (no more than 80 characters). Checking the "Preserve my preformatted text" box prevents the system from discarding these manual breaks.

Check the box next to each of the four uploaded files and click "Add Files and/or Refresh View". It is essential that the upload be complete before you take this step. Otherwise, you'll end up releasing corrupted files.

For each of the released files, select a processor and file type, then click "Update/Refresh". Unfortunately, the interface does not allow this to be done in one step: you must submit the settings for one file before moving on to the next one. For DrJava releases, use the following settings:

Keep this page open with the "Email Release Notice" section ready to go, but don't send the email until you've finished the other steps.

Post a news item announcing the new release (follow the "News" link). This can contain the same text as the Release Notes, but should not contain manual line breaks. Again, you may want to look at some older announcements to help maintain a consistent style.

If necessary, upload the javadoc zip file to CSNet.

Log in to the javaplt account on CSNet: ssh javaplt@plt06.cs.rice.edu.

Change to the javadoc directory (/home/javaplt/public_html/drjava/javadoc). For backup, temporarily move the old javadocs somewhere (drjava-old works). Now copy the new javadoc zip to this directory, unzip it, move/rename the unzipped javadoc directory (mv drjava-version-tag/javadoc drjava), and clean up all the remaining junk (an empty unzipped directory, the zip file, and the old javadocs).

In the top-level DrJava site directory (/home/javaplt/public_html/drjava), update LATEST_VERSION.TXT (or whichever of the *VERSION.TXT files is applicable). In order to avoid inserting extraneous line breaks in the file, use the echo: echo -n version-tag > LATEST_VERSION.TXT. It is important not to manually edit these files, as doing so will probably insert newlines, which will break the links on the Web site.

If releasing a beta, changing from a beta to a stable, or otherwise changing which releases should be publicly displayed, edit the main.shtml and download.shtml files to hide or show the appropriate sections. include statements can be hidden by simply changing the space character immediately preceding "include" to a hash (#) character, and vice versa.

Run the drjava-update-news script, which updates the copy of news items on the DrJava Web site.

Make sure everything on the updated Web site looks good: http://www.cs.rice.edu/~javaplt/drjava. Verify that the linked-to files are the correct versions, and that they can be successfully downloaded and run.

Copy the javaplt version of the site to http://drjava.org using the script drjava-cs-to-sf (do not type this command backwards, or you'll end up copying from the main site instead of to it, overwriting your changes!).

Finally, announce the changes. Submit the "Email Release Notice" option from the SourceForge File Release page. Send a brief announcement to drjava-hackers@lists.sf.net, javaplt@rice.edu, drjava@rice.edu, and, for beta and stable releases, drjava-users@lists.sf.net. While we're not consistent about it, it may also be useful to update catalog sites like FreshMeat.net.