Release Process

From Audacity Wiki
Revision as of 17:37, 21 March 2012 by Vaughan (Talk | contribs)

Jump to: navigation, search
The text on this page should only be modified by subscribers to Audacity-devel mailing list.

To understand what this page is for and how it is used, please join that list or read the list archives on Sourceforge.
The discussion page can be used by anyone to make suggestions and comments about this page.


This page defines the Audacity release process.


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 decide on a release date and time. String, manual, and code freeze are two weeks before initial release candidate (rc).
  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. Web site checking using http://validator.w3.org/checklink or similar, and reporting errors/warnings
      4. Wiki changes
      5. A test on the local manual using http://linkchecker.sourceforge.net/ or similar, and reporting errors/warnings
      6. 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 and manual 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.
  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 (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 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 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 code/translations/manual freezes.
  13. Release is complete.
    1. In src/Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
    2. Increment the version number in audacity.dox, src/Audacity.h, and win/compile.txt.

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 audacity-* mailing lists, 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
Personal tools

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