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.
>It's a side effect of not changing often, that it probably doesn't crash too much.
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.
Anyway I phrased that all wrong. I meant to say, that if it doesn't crash as much for you, you can expect that to stay the same throughout the stable release. The changes are universally where the new bugs are coming from. So it follows that you should expect less new bugs, because there are so few changes allowed in the stable distro.
Security fixes and Updates are delivered separately. I don't know this process inside and out but I've been exposed to it for 20 years, here are some more good current links:
> Even stable is updated once in a while. Those updates are called "Point Releases". They usually incorporate the security fixes released until the time of the update and fixes for grave bugs in the current release.
Misleading label to say, e.g. "The horse is unstable." when intending to explain how the horse is outside the stable. (re: Stable == Compound in Debian-speak.)
Hmm, I meant stable compound in the sense of a noble gas, not highly volatile or reactive. Or say, lower energy states that are not as likely to emit a photon.
The horse is "unstable'd", maybe another way of saying it. Unstable is developed outside of the stable release engineering process. That does not mean it's without safeguards. The unstable releases tend to be very stable. There are extra safeguards, and time-based safety measures that protect users of the Stable distribution. They say that Unstable might take longer to get fixes, and while that's likely true in the case of critical fixes with special attention, it's almost never true in practice other than that. Unstable receives fixes much more quickly, in general.
There actually used to be a "debian-volatile" project, too, for things like virus definitions that should be used in a stable distribution, and also didn't make sense to govern through the stable release process, but it is defunct now.
> "Because when it breaks, it is broken in a stable way."
Hubris.
How can you declare something "stable" if you don't perpetually run tests to verify it is indeed "stable"?
And to state the obvious: certain bugs will lead to instability, non-deterministic, and undefined behavior - that's the very nature of things breaking down.
https://wiki.debian.org/LAVA