Dan Fernandez writes about early access to the (due in 2005!) next release of VisualStudio. Simply having these thoughts at all should push you towards a shorter release cycle, IMHO:

Does Microsoft Give Access too Early?
After reading these posts on Whidbey and in thinking about the backlash on Longhorn (too much info too early), it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set such high expectations.  What happens when you see a great feature and you see that it won't be available until the next release?  Some features you like may or may not make Whidbey, it's a technical preview, we really cannot give any guarantee as to what the final product will look like.  As Jay points out, we're even starting to give developers interim builds in a continuous effort to make Microsoft more open to developers.  I would assume this would be a good thing, but there is risk in this approach. The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve.

Well, if you release every 6 to 9 months, that ceases to be a problem. We have given developers access to our ongoing builds for quite awhile now - and I'd have to say that it's been overwhelmingly positive - we get bug reports, bug fixes (admittedly, this is easier for us - a Smalltalk system ships with all sources), and we set expectations very concretely - over time, developers have gained a feel for what we can and can't do within one cycle, and they evaluate the builds based on that. It's interesting to see just how many negatives start to flow from having an extended release cycle...