> >> I think I prefer Richard's suggestion of not branching until we're > >> ready to make the .0 release. The effect should be the same > >> except that people don't have to deal with checking patches in on > >> the branch vs. the trunk until after 4.3.0 goes out. > >> > > > > I like this approach.
Me too. I'm also very pleased that the RM and SC are open and willing to consider changes of this nature to GCC release procedure. Thanks. > So have we come to some sort of consensus here? We leave mainline as > stage 3 until we release? or at least have a somewhat final release > candidate? The summary of this thread is that opening stage 1 before we release hurts us. So, we're trying to figure out another way. I think there is consensus that this is a good idea. Well, maybe not consensus, but all the posted commentary seems in favor. I assume if people objected, they'd say something... > Once we hit the target of 100 open PRs,( or whenever we would have > originally cut a stage 3 release branch), we firm up stage 3 so that > *really* only bugfixes go in. Then we work toward a release > candidate, etc etc.? I guess. This is the part that is less certain to me. There is less consensus here, in that Richard and I are advocating a strict time-based release schedule once the < 100 PR bit is flipped, with staggered RCs. (Richard, I hope this generalized summary is accurate.) Jason and Mark seem to be less impressed with this specific part. > We can play it by ear, but do you want to wait to open stage 1 until > we actually release 4.3, or do it after RC2 or something like that > where there isn't much else going to happen to it? Either works for > me, but I don't see that opening stage 1 before we actually release > buys us much. So, I'd guess Stage 1 opens after 4.3.0 is released, or at least tagged in SVN. -benjamin
