Difference between revisions of "Release Process"

From Audacity Wiki
Jump to: navigation, search
(First things first!)
(Clarify evolving release process.)
Line 1: Line 1:
 
{{Template:Audacity Devel}}
 
{{Template:Audacity Devel}}
  
{{Intro|This page attempts to provide a description of what needs to be done in order to do an Audacity release.|}}
+
{{Intro|This page defines the Audacity release process.|}}
  
 
== Release Manager ==
 
== Release Manager ==
* Appoint a 'Release Manager', one of the 'Tech Leaders'.
+
* Each release has a designated Release Manager, one of the Technical Leaders.
** Release Manager manages the whole process of setting dates etc.
+
** Release Manager manages the whole process, announcing dates, managing freezes, etc.
 
** Release Manager has final say on when a release candidate is good enough for actual release.
 
** Release Manager has final say on when a release candidate is good enough for actual release.
** At the beginning of the release process, announce who is Release Manager, on audacity-devel and audacity-quality.
 
  
== Translations ==
+
== Policies ==
* Set a string freeze date. After this point, no changes are made to any of the translatable strings within Audacity. 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#Updating existing translations|Translating Audacity]].  
+
* String freeze means no changes are made to any of the translatable strings within Audacity.
* Notify the audacity-translation list that the string freeze is happening and what the target completion date is (leaving some time to build the final installers after that date and before the release itself). Final translations aren't needed for initial release candidates however.  
+
* Code freeze means the only code allowed to be changed is to fix release-blocking bugs discovered in testing.
*: For our current Beta releases, which typically occur every two months or less, we are somewhat more relaxed. We tend not to have an explicit string freeze, so giving the flexibility to change translatable strings for a specific reason. Translators are usually given a deadline of 24 hours before Beta release to get translations in.
+
* 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 ==
 +
 
 +
# 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.
 +
# Tech Leaders designate a Release Manager.
 +
# Release Manager announces he/she is RM, specifies release date and time, and freeze dates and times, on audacity-devel and audacity-quality.
 +
# 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#Updating existing translations|Translating Audacity]].  
 +
# Immediately before the code freeze:
 +
## In Audacity.h, set IS_ALPHA to 0. If it is to be a stable release, also set IS_BETA to 0.
 +
## Bump the version number on the front page of the [http://manual.audacityteam.org/index.php?title=Main_Page Manual].
 +
## Prepare and commit README.txt. Most of the content that used to be in README.txt is now on a web page linked to from the README.txt, so this step should be minimal. On that web page, copy "Changes since the last release" and the "Known Issues with the current release" to [[Release Notes]].
 +
# 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.)
 +
# Post final builds/installers to Google Code and to [https://sourceforge.net/projects/audacity/files/ SourceForge] (Beta downloads are not served from SourceForge, but some users still look there, so they should be archived there). '''Delete the rc's from Google Code''' to avoid user confusion and to conserve space.
 +
# Update the zipped manual stored at [http://manual.audacityteam.org/help.zip 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.
 +
# Do the Release Announcements per that section, below.
 +
# Tag the release, per that section, below.
 +
# In Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
 +
# Lift string and code freezes.
 +
 
 +
== Release Candidates ==
  
== Testing ==
 
* Set code freeze date.
 
* Set IS_ALPHA to 0 in Audacity.h so that About dialog shows Beta designation. Set IS_ALPHA back to 1 when freeze is lifted.
 
* Bump the version number on the front page of the [http://manual.audacityteam.org/index.php?title=Main_Page Manual].
 
 
* Build release candidate:
 
* Build release candidate:
 
** Windows [[Release_Process/Win|Installer]] (includes manual)
 
** Windows [[Release_Process/Win|Installer]] (includes manual)
Line 24: Line 40:
 
** Mac Zip (no manual)
 
** Mac Zip (no manual)
 
** Linux [[Building Release Tarballs| Full and Minimal source tarballs]] (single script does both).
 
** Linux [[Building Release Tarballs| Full and Minimal source tarballs]] (single script does both).
* Upload to Google Code so that people can download them for testing. Post the links to these on audacity-devel 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.
+
* Upload to Google Code so that people can download them for testing. Post the links to these on audacity-devel and audacity-quality. 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.
 
* Ensure that installers are tested as well as the zips.
 
* Ensure that installers are tested as well as the zips.
** Past issues indicate need to test installers installing over an existing install.
+
** Test installers installing over an existing install.
** Past issues indicate the need to test on a non-developer machine (in case it relies on features only found on developer machines).
+
** Test on non-developer machines (in case it relies on features found only on developer machines).
* Resolve issues and re-post as needed.
 
* Build final distributions with final translations included in them and post to Google Code and to [https://sourceforge.net/projects/audacity/files/ SourceForge] (Beta downloads are not served from SourceForge, but some users still look there, so they should be archived there). '''Delete the rc's from Google Code''' to avoid user confusion and to conserve space.
 
* Update the zipped manual stored at [http://manual.audacityteam.org/help.zip http://manual.audacityteam.org/help.zip] using the updated Manual from your source tree. Test unzipping the Manual before sending it. When unzipped, it should produce a "help" folder with the "manual" folder inside that. 
 
  
== Website release announcements ==
+
== Release Announcements ==
* Prepare and commit README.txt and copy the "Changes since the last release" and the "Known Issues with the current release" to [[Release Notes]].
 
 
* Create the website release announcement and list of changes from the committed README.txt. Commit the website changes to SVN and [[Editing audacity.sourceforge.net#Updating the web server from SVN|push to the website]] so that it goes into the audacity_website.pot file and is then available to translators.
 
* Create the website release announcement and list of changes from the committed README.txt. Commit the website changes to SVN and [[Editing audacity.sourceforge.net#Updating the web server from SVN|push to the website]] so that it goes into the audacity_website.pot file and is then available to translators.
 
* Make Forum announcement.
 
* Make Forum announcement.
 
* Announce release to mailing lists, GoogleCode Wiki, [https://sourceforge.net/news/?group_id=6235 SourceForge] and the [http://audacity.sourceforge.net/#announce Dreamhost list].
 
* Announce release to mailing lists, GoogleCode Wiki, [https://sourceforge.net/news/?group_id=6235 SourceForge] and the [http://audacity.sourceforge.net/#announce Dreamhost list].
  
==Tag the release in SVN==
+
== Tag the Release ==
  
This is the 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:
+
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" <nowiki>https://audacity.googlecode.com/svn/audacity-src/trunk/ https://audacity.googlecode.com/svn/audacity-src/tags/Audacity_1_3_x</nowiki>
 
  svn copy -m "Tag release of Audacity 1.3.x" <nowiki>https://audacity.googlecode.com/svn/audacity-src/trunk/ https://audacity.googlecode.com/svn/audacity-src/tags/Audacity_1_3_x</nowiki>
 
==Release Management==
 
* We have a firm policy of never providing for download two files with the same name and different contents, e.g. a hotfix to an installer will have a new name.
 
* We haven't yet got a clear policy on what to do if we ever put a bad download up.  Probably it's to deprecate it, and then discuss the solution on audacity-devel.
 
* We haven't yet got a clear policy on hotfixes.  If we do them at all they probably do not require the same testing as true releases get, since that delay reduces their value.
 
  
 
[[Category: For Developers]]
 
[[Category: For Developers]]

Revision as of 00:25, 6 April 2011


This page defines the Audacity release process.

Release Manager

  • Each release has a designated Release Manager, one of the Technical Leaders.
    • Release Manager manages the whole process, announcing dates, managing freezes, etc.
    • Release Manager has final say on when a release candidate is good enough for actual release.

Policies

  • String freeze means no changes are made to any of the translatable strings within Audacity.
  • Code freeze means the only code allowed to be changed is to fix release-blocking bugs discovered in testing.
  • 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 announces he/she is RM, specifies release date and time, and freeze dates and times, on audacity-devel and audacity-quality.
  4. 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.
  5. 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. Most of the content that used to be in README.txt is now on a web page linked to from the README.txt, so this step should be minimal. On that web page, copy "Changes since the last release" and the "Known Issues with the current release" to Release Notes.
  6. 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.)
  7. Post final builds/installers to Google Code and to SourceForge (Beta downloads are not served from SourceForge, but some users still look there, so they should be archived there). Delete the rc's from Google Code to avoid user confusion and to conserve space.
  8. 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.
  9. Do the Release Announcements per that section, below.
  10. Tag the release, per that section, below.
  11. In Audacity.h, set IS_ALPHA to 1, and if it was a stable release, also set IS_BETA to 1.
  12. Lift string and code freezes.

Release Candidates

  • Build release candidate:
  • Upload to Google Code so that people can download them for testing. Post the links to these on audacity-devel and audacity-quality. 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.
  • Ensure that installers are tested as well as the zips.
    • Test installers installing over an existing install.
    • Test on non-developer machines (in case it relies on features found only on developer machines).

Release Announcements

  • 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.
  • Make Forum announcement.
  • Announce 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