From Audacity Wiki
|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 audacity.sourceforge.net
- Create the release announcement for the website, commit to CVS so that it goes into the audacity_website.pot file and is available to translators.
- Merge new strings into .po files in CVS?
- 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.).
- Prepare and commit README.txt and duplicate to Release Notes.
- Write the news announcement and commit it.
- Forum announcement.
- Mailing list, GoogleCode and SF announcement
- Set code freeze date.
- Build release candidate:
- Upload somewhere so that people can download them for testing. Post links on [email protected] Ensure that installers are tested as well as just the exes.
- 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.
- 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.