On Sun, Nov 11, 2018 at 3:54 PM Barry Pollard <[email protected]> wrote:
> 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 http://httpd.apache.org/dev/ space (and associated development tags in 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.
