| This is actually 100% true. Stable is the culmination of the Debian Release Engineering / Testing Freeze process. In Unstable, packages are promoted from Experimental as I understand it which is a comparatively easy threshold to get past. In Testing, packages are only promoted from Unstable if they 1) don't have any bugs open against them, and 2) there is not a freeze on. 50% of the time (1 year) there is a freeze on. In Freeze, only bug fixes are promoted to Testing. New features have to take a number. When the freeze is over, Testing is cut and becomes the new Stable. I might have described some part of this subtly wrong, but this is the Debian release management process in a nutshell. To read more: https://release.debian.org/ In short, "Stable" should be read like stable compound, not like we usually interpret it to mean "doesn't crash" in IT. It's a side effect of not changing often, that it probably doesn't crash too much. The crashing bugs wouldn't have made it into testing, or through the testing/freeze process. Hopefully, at least. I personally prefer to run Unstable on my developer machines, because it gets fixes more frequently: > Security updates are made by the maintainer; they may not be effective on all architectures, and may be delayed. Packages uploaded may not meet release standards, but any breakage is expected to be fixed promptly. Updates are made by maintainers. |
I don't think that's true, it's likely that the actual causes of crashes are better known and documented, I don't think there is a particular way you can make a software release be less likely compared to other releases of the same software.