Do as GNOME does:

1. Set a release date

2. On that date, release

See Martin Michlmayr's Release Management in Large Free Software Projects for some good analysis of this approach in Debian and other free software projects.

(Differs from DropProblemPackages in that packages which do not meet QA goals are released anyway.)

Pros:

Cons:

Opinions:

A full release is a very large undertaking, and I think has different goals. I think releases should attempt to provide particular "large" functionality achievements that involve architectural change (e.g. implementing a new installer, or a SELinux environment), and because of the complexity, ReleaseWhenReady is appropriate. But I think making updates on a fixed schedule could work, and solve many of the niggly problems people have. We have the basic process in place already, it just needs a bit more structure (and more helpers) so that it happens regularly.

See ReleaseProposals for alternatives.