On 1/21/2012 7:05 PM, Justin Sherrill wrote:
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.
Yes, it's double-work if you branch (I assume this is what you mean by tag) and there's several must-fix bugs in there that now have to be fixed in the trunk and the branch. There is a "plus" to tagging and fixing later though: The trunk isn't locked into a freeze while the bugs are being fixed.
Honestly the "must-fix" list/review probably needs to come at least 3 weeks before the desired branch point. There is also a class of bugs that are "nice to fix" that had a spotlight been shown on it before the branch, it would be probably be fixed for the release but its not so critical that it would hold up a release. That's where the "3 weeks" number comes in.
My own inference by reading IRC is that a release will occur pretty quickly after a branch so I'm asking the question: Have we really adequate reviewed the bug list? I'm getting the feeling we're suffering from releasitis due to skipping the last one. At the very least we should be reviewing all the reports that have come in since the 2_12 branch.
John
