Release Process

From Audacity Wiki
Revision as of 00:26, 6 April 2011 by Vaughan (talk | contribs) (Process)
Jump to: navigation, search

This page defines the Audacity release process.

Release Manager

  • Each release has a designated Release Manager, one of the Technical Leaders.
    • Release Manager manages the whole process, announcing dates, managing freezes, etc.
    • Release Manager has final say on when a release candidate is good enough for actual release.


  • String freeze means no changes are made to any of the translatable strings within Audacity.
  • Code freeze means the only code allowed to be changed is to fix release-blocking bugs discovered in testing.
  • We have a firm policy of never providing for download two files with the same name and different contents, i.e., a "hotfix" to an installer will have a new name.
  • Release Manager decides what to do if we post a bad download, and what to do regarding testing and posting hotfixes. (Sometimes, they may not require the same testing cycle as true releases get, since that delay reduces their value.)


  1. Tech Leaders decide on a release date and time. For a beta release, string freeze and code freeze for initial release candidate (rc) are one week before the specified release date. For a stable release, string freeze is two weeks before initial rc, and code freeze is one week before.
  2. Tech Leaders designate a Release Manager.
  3. Release Manager announces he/she is RM, specifies release date and time, and freeze dates and times, on audacity-devel and audacity-quality. All these announcements should start a new thread with a clear header, e.g., "code freeze for 1.3.13rc1".
  4. At string freeze, the audacity.pot file needs to be updated with the frozen strings, and posted to For a Stable release, we would batch update the .po files with the updated messages from the .pot file. See Translating Audacity.
  5. Immediately before the code freeze:
    1. In Audacity.h, set IS_ALPHA to 0. If it is to be a stable release, also set IS_BETA to 0.
    2. Bump the version number on the front page of the Manual.
    3. Prepare and commit README.txt. Most of the content that used to be in README.txt is now on a web page linked to from the README.txt, so this step should be minimal. On that web page, copy "Changes since the last release" and the "Known Issues with the current release" to Release Notes.
  6. After the code is frozen, build and test release candidates for all platforms. Details in Release Candidates section, below. Code is frozen and testing takes place for 48 hours. If any release-blocking bugs are discovered, they are fixed and the next rc builds will be done after the end of that 48 hours. Iterate on this process until the final rc is tested for 48 hours with no release-blocking bugs discovered. (Yes, this process can exceed the designated release date, but it provides at least three 48-hour cycles. It might even be early. Release Manager decides whether to change actual final release date from the target.)
  7. Post final builds/installers to Google Code and to SourceForge (Beta downloads are not served from SourceForge, but some users still look there, so they should be archived there). Delete the rc's from Google Code to avoid user confusion and to conserve space.
  8. Update the zipped manual stored at using the updated Manual from the source tree. Test unzipping the Manual before sending it. When unzipped, it should produce a "help" folder with the "manual" folder inside that.
  9. Do the Release Announcements per that section, below.
  10. Tag the release, per that section, below.
  11. In Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
  12. Lift string and code freezes.

Release Candidates

  • Build release candidate:
  • Upload to Google Code so that people can download them for testing. Post the links to these on audacity-devel and audacity-quality. Within the code freeze period, monitor the Forum, and report bugs to audacity-devel as well as in the Forum thread. Raise a Px Bugzilla issue if the problem is not to be fixed for release.
  • Ensure that installers are tested as well as the zips.
    • Test installers installing over an existing install.
    • Test on non-developer machines (in case it relies on features found only on developer machines).

Release Announcements

  • Create the website release announcement and list of changes from the committed README.txt. Commit the website changes to SVN and push to the website so that it goes into the audacity_website.pot file and is then available to translators.
  • Make Forum announcement.
  • Announce release to mailing lists, GoogleCode Wiki, SourceForge and the Dreamhost list.

Tag the Release

This is the SVN command to use, per Richard's advice; it performs a minimal copy server-side instead of copying the whole thing from your working copy and thus runs very quickly:

svn copy -m "Tag release of Audacity 1.3.x"