There seem to be two groups:
1) Early adopters: release early, release often; more features the better 2) The masses: easy does it, don't break anything, don't release so often
I believe we can satisfy both groups--not perfectly, but good enough.
This is partly summary and partly suggestion for terminology and schedule. I propose doing:
Release name/type Version Schedule
Major releases 2.4 1.5 - 3 years Bugfix releases 2.2.1 ~ 3 months or as needed Development releases 2.3a0 ~ 3 months
Don't get hung up on the version numbers, it doesn't matter. If we agree on the concept, we can name it later.
'Major' releases (roughly corresponding to Linux kernel even releases) would occur every ~ 18-36 months. These releases would be full executable, doc, etc. This seems to be the crux of what many people want. They want a vibrant changing language. But they don't want to have to deal with that change. They want longer cycles. We are talking about users of the language, not hard-core developers. These releases would still go through the alpha, beta, gamma releases. The last development release in a cycle would become the first alpha.
Bugfix or point releases (eg, 2.x.y) would be made as needed, ~ 3 months. These releases would still go through the alpha, beta, gamma releases. This release would be concurrent with the development release.
Since 2.2 is out there, I would suggest putting the bug fix effort only into it. There doesn't seem to be enough people to share the load for keeping 2.1 in good shape.
Development releases, which are source only, could be released approximately every 3 months. These are basically alpha releases. They roughly correspond to Linux kernel odd releases. This would be to satisfy those that want new features or to test compatibility and are willing to build from source. These should be able to be released with very little effort.
The benefits of this scheme is that I think it will appeal to a large majority of people regardless of whether they are an early-adopters or not. The only real drawback is that it will take more time to keep up the previous released version. However, I think this can be minimized by having everyone try to backport their work if it's a bug fix and have several people handle the patches for bug fix releases. I would volunteer to help Michael (or whoever rolls 2.2.2), although I don't have enough time to be the One.
I don't think the numbering/labeling scheme is important. Does it really matter if we call the next release 2.4, 3.0, 2.3-RELEASE or whatever. I personally think the Linux versioning is the most well known and a bit more normal for most people over BSD.