Difference between revisions of "Release Process"

From Audacity Wiki
Jump to: navigation, search
(RC02 is out with the testers. Yah-hoo!)
(now at rc03)
Line 89: Line 89:
 
* {{done}} '''Freeze manual'''
 
* {{done}} '''Freeze manual'''
 
* {{done}} In Audacity.h, set '''AUDACITY_BUILD_LEVEL to 2'''.
 
* {{done}} In Audacity.h, set '''AUDACITY_BUILD_LEVEL to 2'''.
−
* {{done}} Make RCs (e.g. RC1) and place on FossHub audacity-devel ''(or drop box if unavailable)'' [x=02]
+
* {{done}} Make RCs (e.g. RC1) and place on FossHub audacity-devel ''(or drop box if unavailable)'' [x=03]
 
** {{done}} RCx Win exe
 
** {{done}} RCx Win exe
 
** {{done}} RCx Win zip
 
** {{done}} RCx Win zip

Revision as of 17:50, 27 April 2020

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 2.4.0

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

  • Done.png Candidates for RM step forward.
  • Done.png Team designate a Release Manager.
  • Done.png Release Manager announces he/she is RM.
  • Done.png RM announces proposed timeline and proposed scope
  • Done.png RM increments the version number in:
    • Done.png src/Audacity.h
    • Done.png win/build.txt
    • Done.png appveyor.yml
    • Done.png audacity.dox
    • Done.png AC_INIT in configure.ac. (it affects the value in the .pot file as well as tarballs etc)
    • 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
  • Done.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
  • Done.png RM checks codesigning certs, to ensure validity at planned time of use.


Middle Stage

  • Done.png Lots of development happens here.
  • Done.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

  • Done.png Proposed string freeze data announced.
  • Done.png Active work on strings to get them ready for translation.
  • Done.png Last minute tweaks to parameters, error messages and features where names/strings will be affected.
  • Done.png Last minute changes to manual.
    • Done.png Spot tests on alpha manual. (in the past, we've been caught by mediawiki upgrades breaking the script)
  • Done.png String Freeze announced. (one or two week's duration).
  • Done.png Translators given .pot files to work on.
  • Done.png Translations updated in Audacity.
  • Done.png End of translation announced.
  • ToDo.png Write http://wiki.audacityteam.org/wiki/Release_Notes_2.4.0 - a brief user-friendly overview of 2.4.0 (checksums will come later)
  • ToDo.png Write http://wiki.audacityteam.org/wiki/Release_Notes_2.4.0/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.
  • Done.png RM updates README.txt, creating new "Changes in version" text and moving the old text to the top of CHANGELOG.TXT.
  • Done.png Sanity check installer on Win
  • Done.png Sanity check .dmg on Mac.
  • Done.png Sanity check tarball on Linux
  • Done.png Code Freeze announced.


RCs

  • Done.png Check with manual team that there are no P1s in manual.
  • Done.png RM Reviews all P2s
  • ToDo.png RM Prepares release announcement on WordPress website (but do not make live)
  • Done.png Freeze manual
  • Done.png In Audacity.h, set AUDACITY_BUILD_LEVEL to 2.
  • Done.png Make RCs (e.g. RC1) and place on FossHub audacity-devel (or drop box if unavailable) [x=03]
    • Done.png RCx Win exe
    • Done.png RCx Win zip
    • Done.png RCx Mac dmg
    • Done.png RCx Linux tarball
    • Done.png RCx Manual zip
  • ToDo.png Generate the checksums and post at Release Notes 2.3.3
  • 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 RM: Post final builds/installers (including manual.zip) to FossHub.
  • ToDo.png Push the updated copy of the manual to https://github.com/audacity/audacity-manual
  • 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.

Release is complete!

Release Announcements

Website Changes

Wiki

Social Media etc

  • ToDo.png RM: Announce the release to audacity-* mailing lists, SourceForge
  • ToDo.png Peter: Announce to Facebook (and top pin?)
  • ToDo.png Peter: Update Audacity Wikipedia page
  • ToDo.png Steve: Peter: Make the Forum announcement.
  • ToDo.png Steve: Update on KVR
Retrieved from "https://wiki.audacityteam.org/w/index.php?title=Release_Process&oldid=40797"