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.
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.
If bug not fixed
you will be in trouble;
if codefreeze === true
fix your local version;
update the dev version on SVN;
goto manager;
state the severity of the bugs;
follow her direction because she already got a plan;
The thing I could think of in this situation is to avoid problems,
If bug not fixed
you will be in trouble;
if codefreeze === true
fix your local version;
update the dev version on SVN;
goto manager;
state the severity of the bugs;
follow her direction because she already got a plan;
Code freeze usually means all currently known bugs will not be fixed. (And hopefully it goes without saying, no new features are added). If bugs are found during freeze, they add new information, and depending on the view of triage, the code may need to be temporarily "unfrozen" to make a bug fix. Hopefully changes made during code freeze are very carefully reviewed.
It's estimated that one in three bug fixes introduces a new bug of random severity. Code freeze gives you time to "convert" unknown bugs (of variable severity) into known bugs, of known severity.
A true "code freeze" where nothing could be changed would be pointless - what if you found a major bug? You couldn't just ignore it.
In our case, we are branching when we start the alpha (the main branch remains dormant for a while) and we code freeze (no more commits) right before the first customer shipment when we decided that we are done fixing defects.
In the past, I have worked at a company where code freeze really meant feature freeze (no more features added) and branching. Then, we were working on defects.
I would not call what you describe a code freeze but more the creation of a packaging branch where you iron out the details and prepare your code for release.
AFAIK "Code Freeze" actually, uncynically, means "New Code Freeze". The purpose of this is stability for debugging, bug fixes not being included in the freeze because they aren't new code, but fixes to old code.
We prefer the term "down tools" for when you really really mean hands off the code.
Is your freeze really a code freeze or is it a functionality freeze? It's not 100% clear from your question.
Having said that, I'd agree with the above comments about branching and merging. This allows you and your developers to use the branch to fix the bugs you know about and the the ones that will come in over the next few weeks. It then allows you to integrate any critical bug fixed back into the main (frozen) line in a controlled manner.
This way you can hopefully fix the most serious problems without introducing too many new defects. Integration and regression testing are important here.
发布评论
评论（7）
这是一种平衡行为。
一方面，有一个代码冻结期是件好事，但另一方面，如果你发布的产品存在严重问题，足以让你的客户离开，这对任何人来说都不符合任何人的利益。
如果问题足够严重，如果这是我的产品，那么任何代码冻结都不会阻止我修复它们。
祝你好运！
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!
我认为实际的代码冻结是不可能的。 通常，当发生代码冻结时，会进行更密集的测试。 然后呢？ 发现的问题都是下一个版本的文档吗？ 如果您发现问题严重到关键功能无法工作怎么办？
你必须有一种方法来处理每个出现的问题/错误。由于大多数优秀的开发人员都是懒惰的（意见），分支\标记并强制开发人员合并或复制他们的更改到两个地方将阻止他们中的大多数人尝试进行并非 100% 必要的更改。
从那时起，您需要处理出现的每个错误/问题。每个错误/问题都必须根据以下因素进行加权：问题是什么、问题影响是什么、距离最终发布需要多少天进行重新测试。 每个问题的成本效益比。 只有这样才能做出明智的决定。
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.
在这种情况下我能想到的就是避免出现问题，
The thing I could think of in this situation is to avoid problems,
代码冻结通常意味着所有当前已知错误都不会得到修复。 （希望不言而喻，没有添加新功能）。 如果在冻结期间发现错误，它们会添加新信息，并且根据分类的视图，代码可能需要暂时“解冻”以修复错误。 希望代码冻结期间所做的更改得到非常仔细的审查。
据估计，三分之一的错误修复会引入随机严重性的新错误。 代码冻结使您有时间将未知错误（严重程度不同）“转换”为已知严重程度的已知错误。
真正无法更改任何内容的“代码冻结”是毫无意义的 - 如果您发现重大错误怎么办？ 你不能忽视它。
Code freeze usually means all currently known bugs will not be fixed. (And hopefully it goes without saying, no new features are added). If bugs are found during freeze, they add new information, and depending on the view of triage, the code may need to be temporarily "unfrozen" to make a bug fix. Hopefully changes made during code freeze are very carefully reviewed.
It's estimated that one in three bug fixes introduces a new bug of random severity. Code freeze gives you time to "convert" unknown bugs (of variable severity) into known bugs, of known severity.
A true "code freeze" where nothing could be changed would be pointless - what if you found a major bug? You couldn't just ignore it.
在我们的例子中，当我们启动 alpha 时我们正在分支（主分支保持休眠一段时间），并且当我们决定完成修复缺陷时，我们在第一个客户发货之前冻结代码（不再提交）。
过去，我曾在一家公司工作过，其中代码冻结实际上意味着功能冻结（不再添加更多功能）和分支。 然后，我们开始研究缺陷。
我不会将您所描述的称为代码冻结，而是创建一个打包分支，您可以在其中解决细节并准备发布代码。
In our case, we are branching when we start the alpha (the main branch remains dormant for a while) and we code freeze (no more commits) right before the first customer shipment when we decided that we are done fixing defects.
In the past, I have worked at a company where code freeze really meant feature freeze (no more features added) and branching. Then, we were working on defects.
I would not call what you describe a code freeze but more the creation of a packaging branch where you iron out the details and prepare your code for release.
AFAIK“代码冻结”实际上，讽刺的是，意味着“新代码冻结”。 这样做的目的是为了调试的稳定性，错误修复不包含在冻结中，因为它们不是新代码，而是对旧代码的修复。
当您真的真正想要放弃代码时，我们更喜欢使用“down tools”这个术语。
AFAIK "Code Freeze" actually, uncynically, means "New Code Freeze". The purpose of this is stability for debugging, bug fixes not being included in the freeze because they aren't new code, but fixes to old code.
We prefer the term "down tools" for when you really really mean hands off the code.
您的冻结实际上是代码冻结还是功能冻结？ 从你的问题来看并不能100%清楚。
话虽如此，我同意上面关于分支和合并的评论。 这允许您和您的开发人员使用该分支来修复您知道的错误以及未来几周内将出现的错误。 然后，它允许您以受控方式将修复的任何关键错误集成回主（冻结）行中。
通过这种方式，您有望解决最严重的问题，而不会引入太多新缺陷。 集成和回归测试在这里很重要。
Is your freeze really a code freeze or is it a functionality freeze? It's not 100% clear from your question.
Having said that, I'd agree with the above comments about branching and merging. This allows you and your developers to use the branch to fix the bugs you know about and the the ones that will come in over the next few weeks. It then allows you to integrate any critical bug fixed back into the main (frozen) line in a controlled manner.
This way you can hopefully fix the most serious problems without introducing too many new defects. Integration and regression testing are important here.