Release Process

From Audacity Wiki
Revision as of 21:53, 28 February 2010 by Galeandrews (talk | contribs) (update the Manual version number and the zipped Manual)
Jump to: navigation, search

This page attempts to provide a description of what needs to be done in order to do an Audacity release.


  • Set a string freeze date. After this point, no changes are made to any of the translatable strings within Audacity. 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.
  • Notify the audacity-translation list that the string freeze is happening and what the target completion date is (leaving some time to build the final installers after that date and before the release itself). Final translations aren't needed for initial release candidates however.
    For our current Beta releases, which typically occur every two months or less, we are somewhat more relaxed. We tend not to have an explicit string freeze, so giving the flexibility to change translatable strings for a specific reason. Translators are usually given a deadline of 24 hours before Beta release to get translations in.


  • Prepare and commit README.txt and duplicate the current changes and Known Issues therefrom to Release Notes.
  • 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 to mailing lists, GoogleCode Wiki, SourceForge and the Dreamhost list.


  • Set code freeze date. Within the code freeze period, report bugs on -devel list, as well as raising a Px Bugzilla issue.
  • Bump the version number on the front page of the Manual.
  • Build release candidate:
  • Upload to Google Code so that people can download them for testing. Post the links to these on [email protected] and the Forum. Ensure that installers are tested as well as the zips.
    • Past issues indicate need to test installers installing over an existing install.
    • Past issues indicate the need to test on a non-developer machine (in case it relies on features only found on developer machines).
  • Resolve issues and re-post as needed.
  • Build final distributions with final translations included in them and post 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.
  • Update the zipped manual stored at using the updated Manual from your source tree. Test unzipping the Manual before sending it. When unzipped, it should produce a "help" folder with the "manual" folder inside that.

Release Management

  • We have a firm policy of never providing for download two files with the same name and different contents, e.g. a hotfix to an installer will have a new name.
  • We haven't yet got a clear policy on what to do if we ever put a bad download up. Probably it's to deprecate it, and then discuss the solution on audacity-devel.
  • We haven't yet got a clear policy on hotfixes. If we do them at all they probably do not require the same testing as true releases get, since that delay reduces their value.