Release Process

From Audacity Wiki
Revision as of 00:02, 30 August 2013 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. The Release Manager
    • Manages the whole process, announcing dates, managing freezes, etc.
    • Has final say on when a release candidate is good enough for actual release.
    • Release Manager (and occasionally other Technical Leaders) are the only people allowed to change this page during the release cycle. Others should only add suggestions between release cycles, and not change the basic process definition.


  • "Freeze" for code/translations/manual means that the only allowed changes are to fix release-blocking issues discovered in testing release candidates. That includes not modifying/upgrading the underlying software infrastructure for the manual because it can affect manual retrieval.
  • 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 designate a Release Manager. Release Manager announces he/she is RM.
  2. RM proposes freeze date, checks that we are ready to go, and confirms that any long-lead-time tasks will be started early. Ready to go means: No known release blockers and/or all P1's (and possibly some P2's, at RM's discretion) have commitments to fix in time. No blocking issues around documentation or translation, or have commitments to fix in time. Need:
    1. commitments to build RCs for all platforms:
      1. Win exe (installer) and zip
      2. Mac dmg and zip
      3. Linux 'minimal source tarball'
    2. commitment to do audacity.pot
    3. commitment to do Release Notes
    4. commitment to update Web site, including checking using or similar, and reporting errors/warnings
    5. commitment to Wiki changes
    6. commitment to Make the manual ready for builders (see Create Local Manual)
  3. RM decides and specifies release date and time. As far ahead of this planned release date as possible, update and post audacity.pot, as specified below. Code/string freeze is first. Manual/README freeze happens ASAP, usually about 24 hours later.
    1. 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, creating new "Changes in version" text and moving the old text to the top of Section 6 "Previous Changes". The list of Known Issues at time of release is now prepared in the Wiki Release Notes for that version, so just link to that page in the README.
    2. At string and manual freeze, the audacity.pot file needs to be updated with the frozen strings, and posted to Batch update the .po files with the updated messages from the .pot file. See Translating Audacity.
  4. Once manual is frozen:
    1. Follow Create Local Manual. Eventually we want to have a cross-platform script that will do it all, including the zipping. Hopefully these instructions will become more complete during the 2.0.1 release.
    2. Iterate as manual changes.
  5. Ready for Release Candidates (rc's). The people who do the above tasks report to RM when complete, then RM announces on audacity-devel, audacity-quality, audacity-translation, and Forum when *all* are complete, that it's time to build and test rc's for all platforms. Details in Release Candidates section, below. Code is frozen and testing takes place for 48 hours. RM announces each subsequent rc, as needed.
    • 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 (remember to include any new version of the manual). For each new RC series, deprecate the previous set.
    • 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.) Note that the step below, 'Release Announcements', can be done in parallel from this point.
  6. This and the next two steps should be expected to take about 24-36 hours.
    1. Post final builds/installers (including to > Downloads.
      1. Delete the rc's including the manual (don't forget deprecated ones) to avoid user confusion and to conserve space.
      2. Set all the previous version files to "Deprecated".
      3. Set all the new version files to "Featured".
    2. Post final builds/installers/manual zip to SourceForge. It is important to keep posting to SourceForge, because Google Code is blocked by some ISP's/countries, plus some users still look for Audacity releases on SourceForge, for historical reasons.
      1. Set the default download for each platform. For each, click on the 'i' button for the file, then check the appropriate checkbox(es) in the "Default Download For:" section. This means that on the SourceForge Audacity project page, the big green download button offers the Windows installer, on Mac the DMG, and on Linux the minsrc tarball.
  7. Upload the manual from which the final was created to to provide an online version of the released manual. The internal structure of the manual is complex, but currently the best option for future releases is to open the dumped manual at \help\manual, copy the four folders (images, m, man, manual) and three files (quick_help.html, index.html, favicon.ico) to the "htdocs/o" directory on the server.
  8. Do the Release Announcements per that section, below.
  9. Tag the release, per that section, below.
  10. Lift code/translations/manual freezes.
  11. Release is complete.
    1. In src/Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
    2. Increment the version number in audacity.dox, src/Audacity.h, and win/compile.txt.

Release Candidates

Our current policy is to ship no Modules (e.g., mod-nyq-bench), so for Windows and Mac, RC builders should make sure no Module is included in the RC.

  1. Build release candidate:
    1. Windows Installer (includes manual)
    2. Windows Zip (no manual)
    3. Mac DMG (includes manual)
    4. Mac Zip (no manual)
    5. Linux Full and Minimal source tarballs (single script does both).
  2. Upload to Google Code so that people can download them for testing. Post the links to these on audacity-devel, audacity-quality, and the Forum. 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.
  3. Ensure that installers are tested as well as the zips.
    1. Test installers installing over an existing install.
    2. Test on non-developer machines (in case it relies on features found only on developer machines).

Release Announcements

  1. Make the necessary website changes including creating the website release announcement (usually only a few lines) from the committed README.txt. Start making and testing the changes early enough bearing in mind what needs to change.
  2. Copy the new "Changes in version" text from the README into the Wiki Release Notes.
  3. Go to to see the P1/2/3 bugs (including WONTFIX with that rating).
    1. Export the CSV.
    2. Feed it through to convert (some) to Wiki formatting.
    3. Tidy up the bugs list so there are no duplicate categories/missing bullet points etc.
  4. Go to the Release Notes for the previous version, and change the "intro" div to give the dates the version was current for. Add a link to the Release Notes for the version just released.
  5. Clear the text on .
  6. <deprecated for 2.0.4, remove after>Write the news item.</deprecated for 2.0.4, remove after>
  7. Update for that developer news item, delete the oldest news item, and update the version number for links to "Online Audacity Manual" and "Downloadable Manual for Audacity".
  8. When 1 - 7 are fully complete, 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.
  9. Make the Forum announcement.
  10. Announce the release to audacity-* mailing lists, SourceForge, and the Dreamhost list.

Tag the Release

Since 2.0.0, we tag both audacity-src and website.

This is the template 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"

For TortoiseSVN, in the Branch/Tag dialog, use the HEAD radio button option to get this server-side copy.