Guys, I think we are not currently in a state to handle time-based releases. Until we can cut master at any time and have it releasable, or at least at a reasonable RC-level matching minimum tested requirements, it's just going to continue to be an exercise in frustration to cut RCs simply because we hit a deadline.
Maybe we can get away with sticking to time-based if we revamp our schedule and procedures, I don't know, but in light of how 4.1 (dragged on so long that some were seriously considering skipping/not releasing it with 4.2 on its heels) and 4.2 (six rounds of votes so far) have worked it's probably worth discussing. Any suggestions on what might be better? It's been mentioned in the past that it's a chicken-egg thing, many really don't try it until we hit an RC, which causes multiple iterations. I do agree that many don't take it seriously until we start cutting artifacts, but maybe we do this in a more deliberate fashion instead of jumping right to the vote. After feature/code freeze, cut some alpha artifacts, wait a week, cut alpha2 or some beta artifacts, etc, and then at some point anyone can propose that certain artifacts (or a new set of artifacts) be put up for a vote as an RC. This gives us a way to signal that we're gearing up for release and gives plenty of time for people to test their components, or see the [PROPOSAL] and say 'oh crap, I had better test my stuff', prior to cutting an RC. Maybe this wouldn't help in practice, but I think right now we go from telling the community "code is frozen, don't check anything in unless its a bug fix" to "here's our RC, try it out", without a formal testing window. I realize the whole thing should be a testing window, but I don't think it's conveyed well.
