On Sat, Jan 21, 2012 at 3:44 AM, John Marino <dragonfly...@marino.st> wrote:
> A lot of new material was committed since the 2.12 branch. It's not like we > were in a freeze. So 3.0 is not a relabeled 2.12, and a new set of bugs > could have been created. > > Plus I think a formal review of the buglist for each release should be part > of release planning. It forces us at least once every 6 months to really > review it, and give the users/developers a platform to opine on what really > needs to be fixed and what can wait. > Applying back to the releas branch is kind of a pain, and at least two of us > have made "git" mistakes doing it. Our goal (and I think it's Matt goal > too) is that the actual release is pretty similar to what's tagged. Is it really so much trouble to have a tag, then test against that tagged version, that it is better to tag and release all at once instead? I like having something specific to test against, that we know is the target, especially after being almost nearly about to release for the last 6 months. I can appreciate a code review and that there could be a whole new slew of bugs, but tagging something shouldn't interfere with any of that. I tagged 2.12 and it would have been releasable as 2.12.1 very quickly if that wierd probably-an-AMD-CPU-bug hadn't been so intractable.
