Mea culpa. I let my enthusiasm get the better of me is when I wrote
> I have been impressed with open source projects that have made the change.
I have gone back and tried to identify smaller projects which have made such a change. To my shame I am unable to find any. Not say that they do not exist (I am sure that they do) but I am unable to formulate a google query that turns any up. (It does not help that there is a prominent software company named Cadence Design Systems :-). That said I would add to Xue Fugiao's list OpenStack (6 month cadence).
Re Eli's points: In my short time at Mathworks it is clear to me that the model is very different from what he imagines. At Mathworks a culture of cadence-base release starts with an absolute awareness that no one knows what will be in the next release. Concretely that translates into _never_ making such commitments to customers. I am told that what corresponds to "roadmap presentations" come down to describing areas that the company views as strategic and hence where it is investing development resources. I have not attended such a presentation (I am, after all, a lowly engineer). Still I have been lead to believe that such presentations are quite honest about relative levels of investment and priorities attached to various development activities. The customers in turn are knowledgeable enough to understand that - to the extant that development resources are fungible - under some circumstance resources may be pulled from lower priority work to accelerate delivery of higher priority work. Eli is correct that there is some attempt at the start of a development cycle to synchronize and coordinate activities that involve cross-group dependencies. But what has struck me most strongly, based on more than 40 years prior experience in commercial software development, is how readily features that had been on a glide path toward shipment in a given release can get cut. The clear message is that shipping a high-quality product on a predictable schedule is more important than delaying the release or shipping something buggy. If a feature was nearly ready for this release then surely it will be in truly great shape for the release 6 months later. So why take a chance? The other part of taking care of customers is quick publication of descriptions of any bugs that do make it into the field, including either publication of work-arounds where appropriate and when necessary rapid availability of bug fix releases containing _nothing_ but high priority bug fixes.
I have been thinking about the difference between Emacs' development culture and that of project with a strong commitment to maintaining a cadence. My conclusion is that it comes down to the effort put into keeping the master branch so healthy that a release branch could be cut at nearly any moment. Inevitably this comes with a strong emphasis on code review, gatekeeping and usually continuous testing. The Linux kernel is somewhat atypical in having its gatekeeping function entrusted entirely to humans (Linus' lieutenants and their underlings). (I am unfamiliar with Firefox. I did read https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ but failed to get a good sense of how things work there.) All of the remaining projects (Chromium, LibreOffice and OpenStack) use gerrit to enforce a review processes (and to support continuous integration testing). The important part of all of these review cultures is that work _must_ be presented in reviewable units. No matter how good the work and no matter how great the reputation of the developer if what is offered for review is too large or amorphous then it is entirely expected that it will be reject with a request to break it up into more digestible units. Keeping the master branch ready for release also means not allowing incomplete work to get promoted. Hence none of these projects would deem acceptable code without supporting documentation or unit tests. Absence of either would be grounds for a failed review.
Re current pattern of 6 month code freeze: This seems to be a manifestation of that fact that once a sufficient collection of new features have been accumulated we recognize in our heart of hearts that our code is not ready for release. At a minimum it has not necessarily been built on all of the platforms we claim to support, various feature have received waivers (hence are incomplete) and lots of documentation remains to be written. Moving more rapidly from cutting a release branch to asserting a release-ready tarball requires addressing those cultural patterns.
/john