Release Process

Changes to this page may need discussion first - especially so during a release!
Suggestions on the talk page are always welcome.

Release Manager

Each release has a designated Release Manager (RM), one of the Audacity Team. The Release Manager
- Manages the whole process, announcing dates, managing freezes, etc.
- Makes stop/go decisions on the release, and other decisions responding to release issues.
- RM will probably use a page on wiki such as Next Release for more detailed tracking of what is going into the release, and the schedule.

Policies

During "Freeze" the only changes are to fix release-blocking issues. No other changes to source code, installer, build scripts, translation files or manual scripts.
P1s, including P1s in the manual, block release. P2s are 'Release Manager decides'.
New files provided for download always need a new name, so a "hotfix" to an installer will have a new name.
Release Manager can override policies, even releasing with a known P1 bug (though they are very unlikely to do that).

Process (James)

Tech Leaders designate a Release Manager. Release Manager announces he/she is RM.
RM announces proposed timeline.
Semifreddo (one week's duration). No new features. Active work on strings to get them ready for translation. Minor tweaks to parameters and features.
1. Typically we will delay Semifreddo by 2 week steps if we are not ready for it, e.g. if we have open P1s.
2. At end of Semifreddo, pot file is updated and .po files regenerated, and announced to translators.
Frozen (two week's duration). Only P1 fixes. [RM may review and allow some P2 fixes too]. No GUI changes. Translation in progress. Updates to manual in progress. Trial of installers etc (using old manual and translations).
1. P1's during Frozen could cause us to abandon the release attempt, as they indicate serious problems that should have been cleared by this stage. RM decides.
2. Active discussion of future plans is perfectly OK during this time.
3. RM reviews all P2s, talking with QA team. RM may block on a P2. This could extend the frozen time, possibly in 1 week steps, or lead to abandoning the release attempt. RM decides.
4. RM prepares (but does not make live) update of website. Links may need checking/review.
5. RM prepares (but does not make live) Wiki release notes. These can still be updated later.
6. RM prepares (but does not send) Release announcement. This can still be updated later.
7. RM prepares and commits README.txt, creating new "Changes in version" text and moving the old text to the top of CHANGELOG.TXT. 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 README.txt.
Towards the end of frozen:
1. Set audacity alpha manual to not show alpha or 'development' at Manual.
2. Freeze manual.
3. Follow Create Local Manual.
4. Do not unfreeze alphamanual until static copy of website has been updated, as it is taken from the alphamanual.
5. At end of frozen, manual and translations are ready and we have update of website and wiki ready to go.
RC1 preparation:
1. In Audacity.h, set AUDACITY_BUILD_LEVEL to 2.
2. Build Win exe (installer) and zip
3. Build Mac dmg and zip
4. Set AC_INIT to the new Audacity version number in configure.ac prior to building the Linux min-src tarball.
RC1. (one week to test).
1. Details are in Release Candidates
We hope not, but if necessary to clear a P1, RC2 and RC3, with total test time for both combined of one extra week.

This and the next two steps should be expected to take about 24-36 hours.
1. Post final builds/installers (including manual.zip) to FossHub.
  1. Delete the RCs 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".
Upload the manual from which the final manual.zip was created to manual.audacityteam.org 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 audacity-src/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.
Check that static copy of manual is updated.
Update version checker script at wordpress website.
Post the Release Announcements.
Tag the release, per that section, below.
Lift code/translations/manual freezes.
Release is complete.
1. In src/Audacity.h, set AUDACITY_BUILD_LEVEL to 0.
2. Increment the version number in audacity.dox, src/Audacity.h, and win/compile.txt.

Release Candidates

We currently don't ship modules (e.g., audacity-src/lib-src/mod-nyq-bench), so for Windows and Mac, RC builders should make sure no module is included in the RC.

Build release candidates:
1. Windows Installer (includes manual)
2. Windows Zip (no manual)
3. Mac DMG (includes manual)
4. Mac Zip (no manual)
5. Linux Minimal source tarball
Upload RC's to FossHub with descriptive string making clear the version and that they are RCs for testing. Post the links to these on audacity-devel, audacity-quality, audacity-translation, and the Forum.
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

Bill 04Sep2017: Updated for 2.2.0 process. There are now 3 pages:

http://wiki.audacityteam.org/wiki/Release_Notes_2.2.0 - a user-friendly overview of 2.2.0
http://wiki.audacityteam.org/wiki/Release_Notes_2.2.0/Issues - the intimidating, complete list of known issues
http://wiki.audacityteam.org/wiki/Release_Notes_2.2.0/Bugs_Fixed - for those who really care, optional

website changes
1. new release announcement, summarizing most important points ~~from the committed README.txt~~ ??
2. Add link to the new post at http://www.audacityteam.org/about/news/
3. Update mentions of program versions, copyright dates, file sizes, and SHA checksums (for installers, .zips, source code, and manual) at:
wiki release notes
1. Create new wiki release notes page, e.g., https://wiki.audacityteam.org/wiki/Release_Notes_2.2.0
2. Create a new wiki known issues page, e.g. https://wiki.audacityteam.org/wiki/Release_Notes_2.2.0/Issues
3. Create a new wiki bugs fixed page, e.g. http://wiki.audacityteam.org/wiki/Release_Notes_2.2.0/Bugs_Fixed - look at previous bugs fixed page for live bugzilla table code
4. ~~Copy the new "Changes in version" text from the README.txt into the new wiki release notes.~~
  This seems to be done the other way around, now? Create the wiki page http://wiki.audacityteam.org/wiki/Release_Notes_2.2.0 , then transfer to README? Should README just have the outline text from Release Notes page with link to the Issues page?
Go to https://bugzilla.audacityteam.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Release%20Notes&sharer_id=5 to see the P1/2/3 bugs (including WONTFIX with those ratings).
1. Export the CSV.
2. Feed it through http://www.catalase.com/bugzilla2wiki.htm to convert (some) to Wiki formatting. Copy and paste its output into the Release Notes 2.2.0/Issues page to replace the contents of the section "Known Issues at Release". If that section contains a sub-section "2.1 Headline issues", paste underneath the Headline issues because that text should be retained. Remove the second half of the paste which is the same content with colored tables, bug ratings and bugzilla links. "Headline Issues" are now on the main Release Notes page.
3. Tidy up the formatting of the paste so there are no duplicate categories, missing or duplicate bullet points, broken links etc. Fix formatting/link problems in the bug's release note on bugzilla (that can be done after release). The most recent bugs are at the bottom of each bug category. Optionally, new important bugs could be moved to the top of their category.
~~Clear the text on https://wiki.audacityteam.org/wiki/Known_Issues~~ Update the live bugzilla table definitions on https://wiki.audacityteam.org/wiki/Known_Issues to capture bugs created or cleared since release (this is the page for issues found after release).
Add a link to the new Release Notes page, to https://wiki.audacityteam.org/wiki/Release_Notes.
Adjust the live bugzilla table in http://wiki.audacityteam.org/wiki/Release_Notes_2.2.1/Bugs_Fixed to freeze it at the date of release (so it won't find bugs fixed after release)
When the above are completed, publish the WordPress website changes that were prepared earlier.
Make the Forum announcement.
Announce the release to audacity-* mailing lists, SourceForge, the Dreamhost list, and optionally Twitter, and Facebook pages.

A list of things to be done after the Release Manager declares "Release".

email to declare Release made and effective with builds uploaded - Release Manager
Ensure Manual no longer has the alpha labeling on the front page - Manual editors
Upload Released Manual - Buanzo
Once the above are completed - unlock the Manual - Manual editors
Prep the alpha Manual for the next release (with alpha designation and version bumps) - Manual editors
Announce on devel mailing list - RM
Announce on WordPress website - RM
Announce on Facebook and top-pin - Peter
Announce on Google+ - James.
Announce on Forum - Steve
Bump version number in footer text on Website - Buanzo
Update Audacity Wikipedia page - Peter
Wordpress 'Check-for-updates link' (from help menu) updated - James
Update on KVR = Steve
Bump bugzilla - add new alpha vn. in "Version" field - James
set IS_ALPHA 1 so new commits can be made - RM

Tag the Release

Since 2.0.0, we tag the release,.

In GitHub create a new version tag.
Ask Buanzo to make an offsite backup of the WordPress database.

Release Process

Contents

Release Manager

Policies

Process (James)

Release Candidates

Release Announcements

Tag the Release

Navigation menu

Views

Personal tools

Search

Navigation

Useful Links

For Developers

For Editors

Tools