Rethinking Stable Releases

[gander]

Why is it that with the release of every major stable version of a package, there always seem to be some errors included? Can't we take a more reasonable approach? Just like before version 1.0, there are Release Candidates - so let's make more Release Candidates. We keep making them, and when we feel it's good enough, we create the final Release Candidate and wait instead of immediately publishing 1.0 with the last batch of errors.

Many packages keep making this silly mistake. They release version after version, preparing for a new major release, but instead of waiting a few days to make sure nothing breaks and it's truly a stable major version, they throw in some errors, fix them, release it as a new package, and almost immediately have to fix it again. What's the logic in that? What's the point? Shouldn't 1.0, or 2.0, or even 5.0 be an indicator of stability?

Instead, when a stable version comes out, I have to wait a few days to make sure nothing crashes or breaks because the author is in a rush to release the stable version even though it isn't really stable.

[typed-sigterm]

Given that it's impossible to test 100% downstream code with a release, although some projects have ecosystem ci.
Note that not all projects have unit/e2e tests. To test 100% downstream code, you must mark it as stable first :)