> I'd rather take the make the dot-zero release approach while branching > and count on interested people fixing bugs on the branch after the > dot-zero release. This way if nobody is interested on a particular > release series then we can declare the dot-zero release final - > otherwise we'd do more releases from the branch anyway.
Quite honestly, I think a version of this basic idea is an improvement over the current vague procedures, and certainly worth trying. I would be open to experimentation in the gcc release procedure, especially after the trials of the 4.2.x series. Aligning Stage 1 freedoms immeidately after the confinements of Stage 3 branch/dot-zero-release seems to be the most natural way to motivate work on Stage 3 fixing/polishing. Our current procedure works against this natural flow. So, the way I see it, something like this: - now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list. - < 100 bugs: mainline freeze, branch, lockdown for two weeks. All hands on board for release. All checkins must have bz#. End two week lockdown with 4.3.0 release candidate 1. - 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. - 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?) Temporary pain for long-term gain. Anyway. I'm surprised this suggestion did not get more comments. This is much more transparent than current procedures, and has a chance of focusing the gcc community on releases, not on the wide-open gates of Stage 1. -benjamin
