Update: Here's the summary and conclusion of discussion.
Update 2: Changes made to the version info page: http://groups.drupal.org/node/150854#comment-508464.
Due to a variety of factors, there hasn't been a point release of Drupal 7 since its 7.0 release, roughly 5 months ago. There are a lot of good bug fixes (some critical/major) and performance improvements in the 7.x branch right now, and the lack of these making it out there for public consumption yet has hampered the ability for contributed module authors to port their modules to Drupal 7, and several other bad effects.
I'm planning to roll the 7.1 release this week, but obviously this won't include all of the fixes to all of the bugs we know about, since some are still in progress, and some don't exist yet. Dries suggested, and I think this is a great idea, that a really good way to help get things rolling along (at least for the initial few releases while we clean up some backlog) is to develop a consistent schedule around Drupal 7 point releases, so if a fix didn't make it into 7.1, there'd be a new target date for a fix making into 7.2 (and 7.3, and so on).
Based on my travel schedule for the next few months, I'd like to propose a new point release of Drupal 7 the last Wednesday of the month. So that would be:
May 25: Drupal 7.1
June 29: Drupal 7.2
July 27: Drupal 7.3
August 31: Drupal 7.4 (just after DrupalCon London, so hopefully we can get some nice fixes in then)
...and so on.
(Note: Actual version numbers might be different, since if there's a security release as well we'll actually increment the number by two: one for just the security fixes, and one for all bug fixes to-date + security fixes.)
We could revisit this policy after 6 months or something and see how it's going and whether we can/should slow it down or keep it going.
I ran this suggestion past the security team first, and didn't see any objections to it. It seems like a great idea to me. What are your folks' thoughts?