From Audacity Wiki
|This page defines the Audacity release process.
- 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.
- 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.)
- 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.
- Tech Leaders designate a Release Manager.
- Release Manager checks with people that we are 'ready to go' (builders for all three platforms, no known release blockers, no blocking issues around documentation or translation, someone to do release notes etc..)
- 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".
- At string freeze, the audacity.pot file needs to be updated with the frozen strings, and posted to audacity.sourceforge.net. For a Stable release, we would batch update the .po files with the updated messages from the .pot file. See Translating Audacity.
- Immediately before the code freeze:
- In Audacity.h, set IS_ALPHA to 0. If it is to be a stable release, also set IS_BETA to 0.
- Bump the version number on the front page of the Manual.
- 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. Copy the new "Changes in version" text from the README into the Wiki page.
- 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.)
- Post final builds/installers to Google Code and to SourceForge (downloads are no longer 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 http://manual.audacityteam.org/help.zip 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.
- Do the Release Announcements per that section, below.
- Tag the release, per that section, below.
- In Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
- Lift string and code freezes.
- 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).
- 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" https://audacity.googlecode.com/svn/audacity-src/trunk/ https://audacity.googlecode.com/svn/audacity-src/tags/Audacity_1_3_x