Release Process

From Audacity Wiki
Jump to: navigation, search
The text on this page should be modified only by Audacity Tech Leaders -- and during release process, only by Release Manager (defined below).


Contents

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.

Policies

  • "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.)

Process

  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. At each step, doer reports completion to RM. Before proceeding, need:
    1. commitments to build Release Candidates ("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 website, including checking using http://validator.w3.org/checklink 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 string/code freeze date and time. As far ahead of this as possible, update and post audacity.pot, as specified below.
    1. Immediately before the code/string freeze:
      1. In Audacity.h, set IS_ALPHA to 0.
      2. 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 README.txt.
    2. After string freeze, the audacity.pot file needs to be updated with the frozen strings, and posted to audacity.sourceforge.net. Batch update the .po files with the updated messages from the .pot file. See Translating Audacity.
  4. Manual freeze happens ASAP after string/code freeze, usually about 24 hours later. Only the Windows installer and Mac DMG RCs (next step) need to wait for this; all other RCs can proceed and be posted in parallel.
    1. Bump the version number on the front page of the Manual.
    2. Once manual is frozen, follow Create Local Manual. Eventually we want to have a cross-platform script that will do it all, including the zipping.
  5. Release Candidates: Details in Release Candidates section, below. Code is frozen and testing takes place for 48 hours, iteratively, until we achieve an RC that we agree is final. The 48-hour countdown starts with RM announcement that all RCs are posted. 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 (including dependency on 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. 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 manual.zip) to audacity.googlecode.com > Downloads.
      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".
    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, BSD, and Solaris the minsrc tarball.
  7. 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.
  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.
    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 Minimal source tarball
  2. Upload to SourceForge so that people can download them for testing. Post the links to these on audacity-devel, audacity-quality, audacity-translation, 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. website changes
    1. new release announcement (htdocs/include/news.inc.php), summarizing most important points from the committed README.txt
    2. htdocs/latest/versions.inc.php
  2. wiki release notes
    1. Create new wiki release notes page, e.g., http://wiki.audacityteam.org/wiki/Release_Notes_2.0.4.
    2. Copy the new "Changes in version" text from the README.txt into the new wiki release notes.
  3. Go to http://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 to replace the contents of the section "2 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.
    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.
  4. Clear the text on http://wiki.audacityteam.org/wiki/Known_Issues.
  5. Add a link to the new Release Notes page, to http://wiki.audacityteam.org/wiki/Release_Notes.
  6. When the above are completed, 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.
  7. Make the Forum announcement.
  8. Announce the release to audacity-* mailing lists, SourceForge, the Dreamhost list, Twitter, and Facebook pages.

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" https://audacity.googlecode.com/svn/audacity-src/trunk/ https://audacity.googlecode.com/svn/audacity-src/tags/Audacity_1_3_x

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

Personal tools

Donate securely by PayPal, using your credit card or PayPal account!