Release Policy

Normal Flow
We are working towards a stable release of Audacity. Beta releases at regular intervals seem to be helpful. Currently (Jan10) it looks as if releases once every two months are about the right frequency. The normal flow should be:


 * A release date is agreed and announced.
 * We have a release master to coordinate the process.
 * A week before the release there is a 'double freeze' announced (see later). We will know who has agreed to coordinate the release and who is doing Linux, Mac, Windows builds, who is doing announcements and wiki updates.  Some care is needed that all bases are covered, e.g Windows with and without installer will nearly always be done by the same person.
 * Releases are made available for testing.
 * Some testing happens. No problems are found.
 * Release master ensures everyone involved has given a good-to-go indication, and announces the release is on.
 * Builds are uploaded by their builders to google.code.

When things go wrong
If in testing some problem is found or if in spite of the double-freeze a risky last minute change has been added that hasn't already had some testing:


 * The release master should decide what to do - obviously based on feedback from others. Options include:
 * Problem is not considered too serious. If it's a bug get a priority for it and handle as a normal P2/P3/P4.  OR
 * New (next few days) release date is announced allowing enough time for more testing and confirmation that everything is really OK. Needs buy-in from those doing the re-spin.  Double freeze is extended a few days. OR
 * That release cycle is abandoned. New version is released with next planned release.

James is generally in favour of option 3 over 2 when things go wrong. Emergency fixes are high-risk.

If after release a build is found to be seriously flawed:


 * The release master should decide what to do - obviously based on feedback from others. Options include:
 * Flag the release as deprecated in google.code
 * Mobilise the group for an emergency fix.

Double Freeze
In progressing towards a stable release we are in 'feature freeze'. That means we are not adding significant new risky features to Audacity core. Features can still be added, #ifdeffed out and as plug-ins. They will not be distributed with beta builds. Some features which are usable, but have rough edges, such as label linking and theming are disabled in beta builds too.

In the week before a release we go into 'double freeze'. This means that any code change to Audacity needs two people with SVN commit rights to agree to it. Wording changes and updates to .po files are exempt from this.

'Stable' relative to P2's
A build can only be called stable if it has no P2's.

The arrival of Windows 7 (and 64 bit Linux) creates an interesting problem. Version 1.2.6 is NOT a stable build for Win7 (and although officially labelled as Stable for Vista, can't with hindsight be regarded as such). A build may be P2 free under XP but have P2's under Win7. However, we are may not be able to get to a stable under Win7 release any time soon.

Possibly the simplest solution is to make it clear on our download site that 1.2.6 is not suitable for Vista, Win7 or Linux 64-bit. On our website we will need to make it clear that we are still working on Win7 support and recommend a better version than 1.2.6 to download as soon as we are sure that there is a better version.

We will only release 2.0 when it has no P2's for WinXP and 32-bit Linux. Once released, our notice that we are still working on Win7 will stay on the site, and point to that version as the best download for Win7.

Release Master
Is it good to have a release master?


 * Pro:
 * There is a clear decision pathway.
 * Against:
 * Possibly undemocratic.
 * Release master might not be doing much of the actual work, just telling others what to do.