On 10/26/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > I've found schedules for GCC to be very hard to predict. As I said in > my status report, our practice has been to cut the release branch when > we reach 100 regressions, and release 2-4 months after that point, > depending on quality on the branch. To be honest, I'd rather wait > longer to make the branch -- but there tends to be intense pressure in > the developer community to make a branch so we can get on to the next > round of major features. In any case, after we make the branch, it's in > regression-only mode, so stability tends to be quite good, though > dot-zero releases are, after all, dot-zero releases.
To jump in on the last fact - dot-zero releases are dot-zero releases - it makes sense to expose the branch to wider testing by, at branching time, exposing a dot-zero release to the public ;) And I seriously dispute that branching and waiting has ever made the branch of better quality just because we branched and waited. Instead the opposite is true - developer ressources are dragged away to work on their stage1 projects (that is true for myself). 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. Which still leaves us with the problem of setting criteria for releasing a dot-zero. Being it 100 regressions or zero P1 bugs or whatever. Early testing certainly helps here (sofar we are doing build-testing only, but I expect to put the built binaries in "production" soon), but there are still serious problems with 4.3 at the moment, like sorting out the libstdc++ API mess. Thanks, Richard.
