Quoting Ben Fowler <ben.the.mole@...400...>:
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
Yeah. What you describe has been our practice since the beginning.
Now, the 0.43 release cycle has been atypically short, with a long freeze relative to the overall length of the cycle. But we did unfreeze immediately after the 0.42 release...
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
It would be nice if the Sourceforge tracker supported that kind of annotation -- ideally I would like the ability to stick in a "release bug", and make its closing dependent on the resolution of various "must-fix" tasks and bugs.
But SF's tracker is too primitive to really support that. :/
-mental