SQLite developer D Richard Hipp has posted to his mailing list to announce a third release in the space of a few days, to fix bugs discovered in version 3.6.10:

Some concern has been expressed that we are releasing too frequently. (Three releases in one week is a lot!) The concern is that this creates the impression of volatility and unreliability. We have been told that we should delay releases in order to create the impression of stability. But the SQLite developers feel that truth is more important than perception, not the other way around. We think it is important to make the highest quality and most stable version of SQLite available to users at all times. This week has seen two important bugs being discovered shortly after a major release, and so we have issued two emergency patch releases after the regularly scheduled major release. This makes us look bad. This puts "egg on our face." We do not like that. But, three releases also ensures that the best quality SQLite code base is available available to you at all times.

He goes on to say that an extended beta period would be unlikely to reduce the risk of bugs found on release, because most bugs in SQLite are found by internal testing rather than by external users. He also argues against withholding releases until they “testing is finished”:

The fallacy there is that we never finish testing. We are constantly writing new test cases for SQLite and thinking of new ways to stress and potentially break the code. This is a continuous, never-ending, and on-going process. All existing tests pass before each release. But we will always be writing new tests the day after a release, regardless of how long we delay that release. And sometimes those new tests will uncover new problems.

Anyone who has ever developed an application will know that sinking feeling when problems are discovered in code that has been distributed. Thoroughly implemented unit testing, as in SQLite, improves quality greatly. When bugs are found though, full disclosure and prompt fixes are the best possible response, so I agree with Hipp’s general approach here.