Difference between revisions of "Release Process"

From Audacity Wiki
Jump to: navigation, search
m (Process)
(Release Announcements: not us any more)
 
(151 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{|width=100%
+
{{intro|This page summarises our release process.  It also (now) serves as a checklist.}}
|-
 
|style="background:#f09050;color:#ffffff;width:100%;text-align:center"|  The text on this page should be modified only by Audacity Tech Leaders -- and during release process, only by Release Manager (defined below).  
 
|}
 
 
 
  
 
== Release Manager ==
 
== Release Manager ==
* Each release has a designated Release Manager, one of the Technical Leaders.  The Release Manager
+
* Each release has a designated Release Manager (RM), one of the Audacity Team.  The Release Manager
 
** Manages the whole process, announcing dates, managing freezes, etc.
 
** Manages the whole process, announcing dates, managing freezes, etc.
** Has final say on when a release candidate is good enough for actual release.
+
** <b>Makes stop/go decisions on the release, and other decisions responding to release issues.</b>
** Release Manager (and occasionally other Technical Leaders) are the only people allowed to change this page during the release cycleOthers should only add suggestions between release cycles, and not change the basic process definition.
+
** 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.
 +
{{note|1='''RM is God'''<br>
 +
This phrase is a slightly tongue in cheek reference to the fact that the RM decides what is in and what is out for each release.  This is a mechanism to reduce argument when there are differences in opinion.  The RM is of course expected to be reasonable, and would not have been trusted with the role if they were thought not to be.}}
  
 
== Policies ==
 
== 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.
+
* P1s, including P1s in the manual, block release. P2s are 'Release Manager decides'.
* 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.
+
* New files provided for download always need a new name, so 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.)
+
* Release Manager can override policies, even releasing with a known P1 bug (though they are very unlikely to do that).
 +
 
 +
==How Tos==
 +
The final section of many of the 'Building On' pages have instructions for building release versions.
 +
 
 +
* '''[[Building The Manual]]''' - For the manual obviously
 +
* '''[[Building On Windows]]''' - We produce both an installer and a zip file
 +
* '''[[Building On Mac]]''' - We just produce a .dmg
 +
* '''[[Building On Linux]]''' - We produce a minimal tarball
  
== Process ==
+
'''Other tables etc...'''
 +
* '''[https://md5file.com/calculator Online Checksum Calculator]''' - For SHA-256's
 +
* <s>'''[[Version Checking Scriptlet]]''' - For our website downloads page</s> no longer used
 +
* <s>'''[[Dynamic Bug List]]''' - For release notes pages</s> no longer used
  
# Tech Leaders designate a Release Manager. Release Manager announces he/she is RM.
+
== Process (James) ==
# 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:
+
'''''The {{done}} and {{todo}} tick boxes are for 3.0.3'''''{{note|1=Some of the steps have been reduced here through improved scripts.  For example, there is no longer a need to modify the alpha manual before fetching a final version, as the changes are made as it is downloaded.}}
## commitments to build Release Candidates ("RCs") for all platforms:
 
### Win exe (installer) and zip
 
### Mac dmg and zip
 
### Linux 'minimal source tarball'
 
## commitment to do audacity.pot
 
## commitment to do Release Notes
 
## commitment to update website, including checking using http://validator.w3.org/checklink or similar, and reporting errors/warnings
 
## commitment to Wiki changes
 
## commitment to make the Manual ready for builders (see [[Create Local Manual]])
 
# 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.
 
##Immediately before the code/string freeze:
 
### In Audacity.h, set IS_ALPHA to 0.
 
### 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.
 
## 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#Updating existing translations|Translating Audacity]].
 
# 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.'''  
 
## Bump the version number on the front page of the [http://manual.audacityteam.org/index.php?title=Main_Page Manual].
 
## 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.
 
# Release Candidates: Details in [http://wiki.audacityteam.org/wiki/Release_Process#Release_Candidates Release Candidates section]. 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.'''
 
# This and the next two steps should be expected to take about 24-36 hours.
 
##Post final builds/installers (including manual.zip) to audacity.googlecode.com > Downloads.
 
###'''Delete the RCs including the manual''' (don't forget deprecated ones) to avoid user confusion and to conserve space.
 
###Set all the previous version files to "Deprecated".
 
###Set all the new version files to "Featured".
 
##Post final builds/installers/manual zip to [https://sourceforge.net/projects/audacity/files/ 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.
 
###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 [https://sourceforge.net/projects/audacity/ 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.
 
#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.
 
# Do the Release Announcements per that section, below.
 
# Tag the release, per that section, below.
 
# Lift code/translations/manual freezes.
 
# Release is complete.
 
##In src/Audacity.h, set IS_ALPHA to 1.
 
##Increment the version number in audacity.dox, src/Audacity.h, and win/compile.txt.
 
  
== Release Candidates ==
+
=== Early Stages ===
 +
* {{todo}} Candidates for RM step forward.
 +
* {{todo}} Team designate a Release Manager.
 +
* {{todo}} Release Manager announces he/she is RM.
 +
* {{todo}} RM announces proposed timeline and proposed scope
 +
* {{todo}} RM increments the version number in:
 +
** {{done}} src/Audacity.h
 +
** {{done}} win/build.txt
 +
** {{done}} audacity.dox
 +
** {{done}} Alpha Manual front page.
 +
** {{done}} Bugzilla front page.
 +
** {{done}} Add to Bugzilla "Version" field.
 +
** {{done}} If needed, increase Copyright year in source code for src/AboutDialog.cpp
 +
* {{todo}} Agreed big/dangerous changes go in, such as new libraries, updating compilers or a switch to 64 bit.  ''This is to allow maximum time for issues with these to be worked out''
 +
* {{todo}} RM checks codesigning certs, to ensure validity at planned time of use.
  
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.
 
  
# Build release candidate:
+
=== Middle Stage===
## Windows [[Release_Process/Win|Installer]] (includes manual)
+
* {{todo}} ''Lots of development happens here.''
## Windows [[Release_Process/Win#Create the zip version|Zip]] (no manual)
+
* {{todo}} ''Lots of bug fixing happens here.''
## Mac [[Release_Process/Mac|DMG]] (includes manual)
 
## Mac Zip (no manual)
 
## Linux [[Building Release Tarballs| Minimal source tarball]]
 
# Upload RC's to SourceForge so they can be downloaded for testing. Post the links to these on audacity-devel, audacity-quality, audacity-translation, and the Forum.  
 
# 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 ==
+
{{note|1=The RM has considerable latitude as to exactly what 'String Freeze' and 'Code Freeze' mean.
# website changes
+
* In '''String Freeze''' changes which will affect translation should not be made.
## new release announcement (htdocs/include/news.inc.php), summarizing most important points from the committed README.txt
+
** A consequence is that many features that might need tweaked text as they develop should not be modified during 'String Freeze'.
## htdocs/latest/versions.inc.php
+
** P1 and P2 fixes are OK in 'String Freeze', and RM may welcome ''any'' bug fixes.
# wiki release notes
+
* '''Code Freeze''' is generally stricter, and generally all changes must be pre-approved.
## Create new wiki release notes page, e.g., http://wiki.audacityteam.org/wiki/Release_Notes_2.0.4.  
+
}}
##Copy the new "Changes in version" text from the README.txt into the new wiki release notes.  
+
 
# 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).
+
=== String Freeze ===
##Export the CSV.  
+
 
##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.
+
* {{todo}} Proposed string freeze data announced.
##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.
+
* {{todo}} Active work on strings to get them ready for translation. 
# Clear the text on http://wiki.audacityteam.org/wiki/Known_Issues.  
+
* {{todo}} Last minute tweaks to parameters, error messages and features where names/strings will be affected.
# Add a link to the new Release Notes page, to http://wiki.audacityteam.org/wiki/Release_Notes.  
+
* {{todo}} Last minute changes to manual.
# When the above are completed, 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.  
+
** {{todo}} Spot tests on alpha manual.  ''(in the past, we've been caught by mediawiki upgrades breaking the script)''
# Make the Forum announcement.
+
* {{todo}} '''String Freeze announced.'''  ''(one or two week's duration)''.
# Announce the release to audacity-* mailing lists, [https://sourceforge.net/news/?group_id=6235 SourceForge], the [http://audacity.sourceforge.net/#announce Dreamhost list], Twitter, and Facebook pages.
+
* {{todo}} Translators given .pot files to work on. 
 +
* {{todo}} Translations updated in Audacity.
 +
* {{todo}} End of translation announced.
 +
* {{todo}} Write http://wiki.audacityteam.org/wiki/Release_Notes_3.0.3 - a brief user-friendly overview of 3.0.2 (checksums will come later)
 +
* <s>{{todo}} Write http://wiki.audacityteam.org/wiki/Release_Notes_3.0.3/Issues - a dynamic complete list of known issues OR fixed issues.</s>
 +
** {{todo}} Final tweaks to the above, taking account of last minute P1s and P2s.
 +
* {{todo}} RM updates README.txt, creating new "Changes in version" text and moving the old text to the top of CHANGELOG.TXT.  
 +
* {{todo}} Sanity check installer on Win
 +
* {{todo}} Sanity check .dmg on Mac.
 +
* {{todo}} Sanity check tarball on Linux
 +
* {{todo}} '''Code Freeze''' announced.
 +
 
 +
 
 +
=== RCs ===
 +
 
 +
* {{todo}} Check with manual team that there are no P1s in manual.
 +
* {{todo}} RM Reviews all P2s
 +
* {{todo}} RM Prepares release announcement on WordPress website  ''(but do not make live)''
 +
* {{todo}} '''Freeze manual'''
 +
* {{todo}} Fetch a copy of the manual.
 +
* {{todo}} In Audacity.h, set '''AUDACITY_BUILD_LEVEL to 2'''.
 +
* {{todo}} Make RCs (e.g. RC1) and place on FossHub audacity-devel ''(or drop box if unavailable)'' [x=01]
 +
** {{todo}} RCx Win exe
 +
** {{todo}} RCx Win zip
 +
** {{todo}} RCx Mac dmg
 +
** {{todo}} RCx Linux tarball
 +
** {{todo}} RCx Manual zip
 +
* {{todo}} Generate the checksums and post at [[Release Notes 3.0.2]]
 +
* {{todo}} Post the links to the RCs on audacity-devel and the Forum.  
 +
 
 +
{{note|1=We may need to repeat with RC2, RC3, if showstoppers are found.}}{{note|1='''Gale's notes on testing:'''
 +
* 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 ===
 +
 
 +
* {{todo}} Push the updated copy of the manual to [https://github.com/audacity/audacity-manual https://github.com/audacity/audacity-manual]
 +
* {{todo}} RM: Post final builds/installers (including manual.zip) to FossHub.
 +
* {{todo}} RM: Post final builds/installers (including manual.zip) to GitHub.
 +
* {{todo}} Tag the release in GitHub.
 +
* {{todo}} Check whether any of the version numbers mentioned in 'Early Stages' can already be updated for the next version.
 +
* {{todo}} In Audacity.h, '''set AUDACITY_BUILD_LEVEL to 0'''.
 +
* {{todo}} '''Lift Code Freeze, String Freeze and Manual Freeze. '''
 +
* {{todo}} In Bugzilla add the new alpha version to the "Version" field.
 +
* {{todo}} In Bugzilla update the message of the day to state the new version.
  
== Tag the Release ==
+
'''Release is complete!'''
  
Since 2.0.0, we tag ''both'' audacity-src and website.
+
== Release Announcements ==
  
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:
+
=== Website Changes ===
 +
* {{todo}} New release announcement on WordPress made live.
 +
* {{todo}} Add link to the new post at http://www.audacityteam.org/about/news/
 +
* {{todo}} Update mentions of SHA checksums (for installers, .zips, source code, and manual):
 +
* {{todo}} Update mentions of program versions, copyright dates, (for installers, .zips, source code, and manual) at:
 +
** {{todo}} http://www.audacityteam.org/about/citations-screenshots-and-permissions/
 +
** {{todo}} http://www.audacityteam.org/copyright/
 +
** {{todo}} http://www.audacityteam.org/download/online-safety-when-downloading/
 +
** {{todo}} http://www.audacityteam.org/download/windows/
 +
** {{todo}} http://www.audacityteam.org/download/mac/
 +
** {{todo}} http://www.audacityteam.org/download/source/
 +
** {{todo}} The version number on the front page (via theme edits).
 +
** {{todo}} The version numbers on download pages (via widget edits).
 +
* <s>{{todo}} Ask '''James''' to update [[Version Checking Scriptlet|version checker script]] at WordPress website.</s>
 +
** The above is struck out, since we no longer have the scriptlet plug-in on our site.
 +
* {{todo}} make an offsite backup of the WordPress database. 
 +
** {{todo}} ensure there is an offsite backup.
  
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>
+
=== Wiki ===
 +
* {{todo}} Update the Audacity Versions page at https://wiki.audacityteam.org/wiki/Audacity_Versions
  
For TortoiseSVN, in the Branch/Tag dialog, use the HEAD radio button option to get this server-side copy.
+
=== Social Media etc===
 +
* {{todo}} '''RM:''' Announce the release to audacity-devel mailing list, [https://sourceforge.net/news/?group_id=6235 SourceForge]
 +
* {{todo}}  Announce to Facebook (and top pin?)
 +
* {{todo}}  Update Audacity Wikipedia page
 +
* {{todo}}  Make the Forum announcement.
 +
* {{todo}}  Update on KVR
  
 
[[Category:For Developers]][[Category:Quality]]
 
[[Category:For Developers]][[Category:Quality]]

Latest revision as of 11:54, 9 July 2021

This page summarises our release process. It also (now) serves as a checklist.

Release Manager

  • Each release has a designated Release Manager (RM), one of the Audacity Team. 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.
RM is God
This phrase is a slightly tongue in cheek reference to the fact that the RM decides what is in and what is out for each release. This is a mechanism to reduce argument when there are differences in opinion. The RM is of course expected to be reasonable, and would not have been trusted with the role if they were thought not to be.

Policies

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

How Tos

The final section of many of the 'Building On' pages have instructions for building release versions.

Other tables etc...

Process (James)

The Done.png and ToDo.png tick boxes are for 3.0.3

Some of the steps have been reduced here through improved scripts. For example, there is no longer a need to modify the alpha manual before fetching a final version, as the changes are made as it is downloaded.

Early Stages

  • ToDo.png Candidates for RM step forward.
  • ToDo.png Team designate a Release Manager.
  • ToDo.png Release Manager announces he/she is RM.
  • ToDo.png RM announces proposed timeline and proposed scope
  • ToDo.png RM increments the version number in:
    • Done.png src/Audacity.h
    • Done.png win/build.txt
    • Done.png audacity.dox
    • Done.png Alpha Manual front page.
    • Done.png Bugzilla front page.
    • Done.png Add to Bugzilla "Version" field.
    • Done.png If needed, increase Copyright year in source code for src/AboutDialog.cpp
  • ToDo.png Agreed big/dangerous changes go in, such as new libraries, updating compilers or a switch to 64 bit. This is to allow maximum time for issues with these to be worked out
  • ToDo.png RM checks codesigning certs, to ensure validity at planned time of use.


Middle Stage

  • ToDo.png Lots of development happens here.
  • ToDo.png Lots of bug fixing happens here.


The RM has considerable latitude as to exactly what 'String Freeze' and 'Code Freeze' mean.
  • In String Freeze changes which will affect translation should not be made.
    • A consequence is that many features that might need tweaked text as they develop should not be modified during 'String Freeze'.
    • P1 and P2 fixes are OK in 'String Freeze', and RM may welcome any bug fixes.
  • Code Freeze is generally stricter, and generally all changes must be pre-approved.

String Freeze

  • ToDo.png Proposed string freeze data announced.
  • ToDo.png Active work on strings to get them ready for translation.
  • ToDo.png Last minute tweaks to parameters, error messages and features where names/strings will be affected.
  • ToDo.png Last minute changes to manual.
    • ToDo.png Spot tests on alpha manual. (in the past, we've been caught by mediawiki upgrades breaking the script)
  • ToDo.png String Freeze announced. (one or two week's duration).
  • ToDo.png Translators given .pot files to work on.
  • ToDo.png Translations updated in Audacity.
  • ToDo.png End of translation announced.
  • ToDo.png Write http://wiki.audacityteam.org/wiki/Release_Notes_3.0.3 - a brief user-friendly overview of 3.0.2 (checksums will come later)
  • ToDo.png Write http://wiki.audacityteam.org/wiki/Release_Notes_3.0.3/Issues - a dynamic complete list of known issues OR fixed issues.
    • ToDo.png Final tweaks to the above, taking account of last minute P1s and P2s.
  • ToDo.png RM updates README.txt, creating new "Changes in version" text and moving the old text to the top of CHANGELOG.TXT.
  • ToDo.png Sanity check installer on Win
  • ToDo.png Sanity check .dmg on Mac.
  • ToDo.png Sanity check tarball on Linux
  • ToDo.png Code Freeze announced.


RCs

  • ToDo.png Check with manual team that there are no P1s in manual.
  • ToDo.png RM Reviews all P2s
  • ToDo.png RM Prepares release announcement on WordPress website (but do not make live)
  • ToDo.png Freeze manual
  • ToDo.png Fetch a copy of the manual.
  • ToDo.png In Audacity.h, set AUDACITY_BUILD_LEVEL to 2.
  • ToDo.png Make RCs (e.g. RC1) and place on FossHub audacity-devel (or drop box if unavailable) [x=01]
    • ToDo.png RCx Win exe
    • ToDo.png RCx Win zip
    • ToDo.png RCx Mac dmg
    • ToDo.png RCx Linux tarball
    • ToDo.png RCx Manual zip
  • ToDo.png Generate the checksums and post at Release Notes 3.0.2
  • ToDo.png Post the links to the RCs on audacity-devel and the Forum.


We may need to repeat with RC2, RC3, if showstoppers are found.
Gale's notes on testing:
  • 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

  • ToDo.png Push the updated copy of the manual to https://github.com/audacity/audacity-manual
  • ToDo.png RM: Post final builds/installers (including manual.zip) to FossHub.
  • ToDo.png RM: Post final builds/installers (including manual.zip) to GitHub.
  • ToDo.png Tag the release in GitHub.
  • ToDo.png Check whether any of the version numbers mentioned in 'Early Stages' can already be updated for the next version.
  • ToDo.png In Audacity.h, set AUDACITY_BUILD_LEVEL to 0.
  • ToDo.png Lift Code Freeze, String Freeze and Manual Freeze.
  • ToDo.png In Bugzilla add the new alpha version to the "Version" field.
  • ToDo.png In Bugzilla update the message of the day to state the new version.

Release is complete!

Release Announcements

Website Changes

Wiki

Social Media etc

  • ToDo.png RM: Announce the release to audacity-devel mailing list, SourceForge
  • ToDo.png Announce to Facebook (and top pin?)
  • ToDo.png Update Audacity Wikipedia page
  • ToDo.png Make the Forum announcement.
  • ToDo.png Update on KVR