Difference between revisions of "Release Process"

Revision as of 23:02, 14 May 2016

Release Manager

• Each release has a designated Release Manager (RM), one of the Technical Leaders. 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)

1. Tech Leaders designate a Release Manager. Release Manager announces he/she is RM.
2. RM announces proposed timeline.
3. 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.
4. 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 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.
5. Towards the end of frozen:
   1. Bump the version number on the front page of the Manual.
   2. Follow Create Local Manual.
   3. At end of frozen, manual and translations are ready and we have update of website and wiki ready to go.
6. RC1 preparation:
   1. In Audacity.h, set IS_ALPHA to 0.
   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.
7. RC1. (one week to test).
   1. Details are in Release Candidates
8. We hope not, but if necessary to clear a P1, RC2 and RC3, with total test time for both combined of one extra week.

1. 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".
2. 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.
3. Post the Release Announcements.
4. Tag the release, per that section, below.
5. Lift code/translations/manual freezes.
6. 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

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.

1. 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
2. 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.
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, summarizing most important points from the committed README.txt
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, publish the WordPress website changes that were prepared earlier.
7. Make the Forum announcement.
8. Announce the release to audacity-* mailing lists, SourceForge, the Dreamhost list, and optionally Twitter, and Facebook pages.

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.