Release Process

From Audacity Wiki
Revision as of 09:46, 16 February 2012 by Mchinen (talk | contribs) (Add mac build 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.

Policies

  • "Freeze" for code/translations/manual means that the only allowed changes are to fix release-blocking issues discovered in testing release candidates.
  • 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 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.
  2. Tech Leaders designate a Release Manager.
  3. Release Manager checks with people that we are 'ready to go', and that any long-lead-time things will be started early
    1. Builders for all three platforms
      1. Win exe (installer) and zip
      2. Mac dmg and zip
      3. Linux 'full source tarball' and 'minimal source tarball'
    2. No known release blockers
    3. No blocking issues around documentation or translation
    4. Someone to do
      1. Release notes
      2. Web site
      3. Wiki changes
      4. what else?
  4. 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".
  5. 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.
  6. 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.
  7. 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.) Note that step 10 below, Release Announcements, can be done in parallel from this point.
  8. This and the next two steps should be expected to take about 24-36 hours.
    1. Post final builds/installers to audacity.googlecode.com > Downloads.
      1. Delete the rc's to avoid user confusion and to conserve space.
      2. Set all the new version files to "Deprecated".
      3. Set all the new version files to "Featured".
    2. Post final builds/installers to SourceForge. (Downloads are no longer served from SourceForge, but some users still look there, so they should be archived there.)
      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 Unicode installer, on Mac the DMG, and on Linux the minsrc tarball.
  9. 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.
  10. Do the Release Announcements per that section, below. Copy the new "Changes in version" text from the README into the Wiki page.
  11. Tag the release, per that section, below.
  12. Lift string and code freezes.
  13. Release is complete. In Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1. Increment the version number.

Release Candidates

  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. 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.
  2. 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 that rating). Export the CSV. Feed it through http://www.catalase.com/bugzilla2wiki.htm to convert (some) to Wiki formatting. Tidy up the bugs list so there are no duplicate categories/missing bullet points etc.
  3. 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.
  4. Clear the text on http://wiki.audacityteam.org/wiki/Known_Issues .
  5. Write the http://wiki.audacityteam.org/wiki/Developer_News news item.
  6. Update http://wiki.audacityteam.org/wiki/Audacity_Wiki_Home_Page for that developer news item, delete the oldest news item, and update the version number for links to "Downloadable Beta Manual" and "Online alpha Manual".
  7. Make the Forum announcement.
  8. Announce the 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
Retrieved from "https://wiki.audacityteam.org/w/index.php?title=Release_Process&oldid=18949"