Differences between version 2 and revision by previous author of FeatureFreeze.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Thursday, July 7, 2005 3:14:33 pm | by IanMcDonald | Revert |
| Older page: | version 1 | Last edited on Wednesday, July 31, 2002 4:24:42 pm | by CraigBox | Revert |
@@ -3,5 +3,5 @@
''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 (an odd-lesser-numbered tree,
such as 2.3 or 2
.5, 2
.n
) is ready to have all its bugs fixed and be released as 2.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.
+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.
