The decision to have time-based releases was made early on with the Apache CloudStack project. It’s fairly standard these days to go with time-based releases rather than feature-based releases, and makes a lot of sense for projects that are primarily aimed at use in corporate IT.
While coming to the decision of time-based vs. feature-based was easy, coming up with the actual length of a release cycle is trickier. Everyone wants the release yesterday, so there’s a strong desire to have a shorter cycle. But a shorter cycle puts pressure on folks to actually get the release out, and a shorter cycle (especially for newer projects) seems more difficult.
We decided initially to go with four-month cycles, but that decision is being revisited right now, with a lot of the community leaning in favor of six-month cycles.
I’d be curious to hear from other projects exactly how they came to decide the length of time-based release cycles. In Linux distribution circles, six-month cycles have been popular – though it looks like Ubuntu is fiddling with that a little bit, and AFAIK, Fedora has generally come closer to seven-month cycles when all is done and said.
For the record, I don’t think we’ve got enough data to decide that four month cycles aren’t workable. I’d really like to see the community take 4.2.0 as the cycle to really refine processes, get more automated testing in place, and try to get documentation folks working together a little better before saying that six-month cycles are a better fit.