You only have to look at the past few attempts (scrapped versions) to release apache to see the dangers in rush rush rush attitude.
I’m assuming it’s a given that httpd should only release when ready to. I don’t think any of the release-often advocates are suggesting taking less care with releases or releasing untested code. My question is would any more testing go on if we did release
less frequently? On one side I get the argument that more time between releases theoretically allows for more testing time, but I question whether anyone would use that time for that? My experience of software development (outside of httpd) suggests not.
Something that is specific to httpd as opposed to other projects...
Many projects today follow the -RC1 -RC2 -RC3 ... final release pattern.
HTTPD project as a collection of patches always agreed that once a tarball
of source code files was assembled, that the number assigned to it would
never change. There would be no post-release changes to that tarball to
designate it as a release.
Therefore in the 2.4.x timeline, roughly 1/3 of the version numbers were
"duds". Nobody observed these outside of the dev@ list and the specific
subversion), because these aren't announced until they are accepted.
This simply does not differ from other major project's success/failure rate
of their -RC1, -RC2 attempts at collecting an "acceptable" release. Only
the naming convention differs.