A FeatureFreeze occurs when you have a development product that you want to become the next stable release.

Using DebianLinux as an example: When the "testing" distribution is mature enough, the release manager starts `freezing' it. The normal propagation delays are increased to ensure that as little as possible new bugs from "unstable" enter "testing". After a while, the "testing" distribution becomes truely `frozen'. This means that all new packages that are to propagate to the "testing" are held back, unless they include release-critical bug fixes. The "testing" distribution can also remain in such a deep freeze during the so-called `test cycles', when the release is imminent.

We keep a record of bugs in the "testing" distribution that can hold off a package from being released, or bugs that can hold back the whole release. Once that bug count lowers to maximum acceptable values, the frozen "testing" distribution is declared "stable" and released with a version number.

The LinuxKernel goes through a similar cycle. Basically, the developers think that the testing version (a versions such as 2.6.n+1.rc-x) is ready to have all its bugs fixed and be released as 2.6.n+1. Instead of adding new features, work progresses on finding and fixing bugs. When the number of bugs is low enough (hopefully zero) the product is released, forked, and people go back to implementing new features in the forked version of it.