Code Freeze when you aren't going to be finished [closed]

Question

I am working on a project that has been running for a long period of time and we're coming up on a final release of the product.

Current testing efforts have discovered there are about thirty defects left in the system, however we don't have time to fix all of these defects (a very common situation I am sure).

I have had several discussions with different people about whether the code freeze should go ahead. Currently my manager wants to keep the code freeze, however to fix remaining critical defects in the window between freeze and release (about 5 weeks). I am worried that this isn't an actual code freeze, but rather a code "slush" at best. The defects will be triaged by a team of senior engineers to make sure that only critical fixes out of the remaining issues are actually worked on, however from an initial look the critical issues seem to number about two thirds of the total outstanding defects.

I understand that having a code freeze presents certain psychological benefits for developers such as providing a fixed end date for all work. However this seems to be completely negated by my manager openly discussing fixes that will go in "after" the freeze.

I was wondering if anyone else has had a similar experience or could provide me with some advice about what the best way to deal with this situation is. I am starting to think that nobody actually freezes their codebase on the day they say they are going to.

We are planning on branching from the trunk in subversion on code-freeze-day to make sure that the final release version of the product is isolated from the development trunk, so I am not too worried about issues of changes being made affecting the release version of the product.

Thanks,

Aidos

EDIT: I suppose the best way to explain my managers' thinking is that it's not really a code freeze, more of a "functionality freeze", however as all of the functionality has been in the product for some time now I think this is a gross oversimplification.

EDIT2: I'd like to thank everyone for their great answers, unfortunately I can only mark one as helpful, even though all 7 answers so far have been incredibly helpful.

Answer 1

It's a balancing act.

On one hand it's nice to have a code freeze period, but on the other, it's in nobody's interest for you to ship a product with critical issues large enough to make your customers walk away.

If the issues are serious enough, no code freeze would stop me fixing them if it were my product.

Good luck!

Answer 2

I think an actual code freeze is impossible. Usually when a code freeze happens, more intensive testing happens. Then what? All the problems that are found are documents for the next release? What if you find a problem so bad that key feature will not work?

You have to have a way of dealing with each problem/bug as they come in. Since most good developers are lazy(opinion), branching\tagging and forcing the developer to merge or copy their changes to 2 places will stop most of them trying to make changes that are not 100% necessary.

From that point on, you need to deal will each bug/problem as they come in. They will each have to weighted according to: What the issue is, what the issue effects, how many days until final release to retest. Cost to benefit ratio for each and every problem. Only then can a sensible decision can be reached.