Answers:
它必须总是可以的，因为没有没有错误的软件之类的东西。
它是一个判断电话。请记住，错误可能有很多。如果其主要功能无法正常使用，请先对其进行修复。如果它对应用程序的有用性影响很小或没有实际影响，则可以让它滑动。
因此，从成本/收益的角度来看它。
当运送已知缺陷的产品的总成本和修复缺陷的风险超过了任何可能带来的问题，并且由于存在缺陷而带来的负面影响时，您便会交付产品。
因此，如果您在发布前有2周的测试期，并且发现了一个小错误，那么问题是...正在修复该错误，现在团队需要花费另外2周的时间来重新测试应用程序和安装（经常忘记创建软件的步骤）？如果软件晚了，声誉或销售的成本是多少？人们会生气吗？如果可以按时交付主要功能，他们可能会很高兴遇到一个小错误。
风险包括引入新问题的风险，不仅是修复错误，还包括创建新安装可能引起的问题。
负面影响是处理报告错误的客户的时间和精力，以及声誉受损之类的事情。
错误的严重性不同。在我工作过的任何软件公司中，我们都按照从P0到P4的优先级对错误进行了分类。
P0是软件无法运行/崩溃，并且可能对客户业务造成损害。P1它不能按设计工作，并且在核心功能中始终崩溃P2它偶尔崩溃，或者某些侧面功能可能不起作用。P3该软件的某些元素未按设计/预期的功能工作。
我在P4无法修复的地方工作，因为它们对软件的影响很小。
我想说的是，如果您的软件已知P3 / P4问题，则可以发货。我将其放在发行说明中，并指出它们正在开发中。
我绝不会发布我所知道的P0，P1或P2问题的软件。
没有错误，您就无法交付软件。我可以提供的建议是，总是比对客户说：“此版本无法做到这一点，但我们将解决此问题”，而不是客户告诉您存在错误的情况。
只要您对客户诚实，就可以附带错误。告诉他们所有现有的错误，就会向他们表明您对软件有很好的了解，并且确实经过了很好的测试（如果确实如此）。:)
显然，最好的办法是避免附带错误。
通常，最好是按时发货并列出已知问题，而不是根本不发货。
在编程世界中，使人们对项目充满信心的一件事是他们是否已计划发布，以及时间表是否成立。
这就是为什么Ubuntu仍然每半年发布一次的原因，即使仍然存在未解决的问题。
正如人们所说，这是一个非常广泛的问题。实际上，这使我进入了一个有趣的角度：您声称的所谓“错误”仅是测试人员发现的错误。可能会有更多的漏洞。刚刚让我想起了我在一次研究生研讨会上从一位受人尊敬的教授那里听到的有趣故事：当一个斯堪的纳维亚国家的人们使用“可识别手写”的投票机时，某些人通过编写恶意的SQL代码来入侵整个系统（系统作为正常输入）。
另一个决定性因素可能是缺陷与您的最新版本的关系。如果错误是新功能但已损坏的功能的一部分，则非功能性并不表示功能的退化。继续运送。
另一方面，如果缺陷导致丢失现有功能，而现有功能已知对现有客户有用，那么它必须阻止发布。这样的发行版对您的客户而言是降级的，对您的利益和他们的利益都不起作用。
可能会有灰色阴影。核心功能的衰退永远都不会消失。如果该发行版还包含他们已表示感兴趣的新功能，则外围功能可能会有些退缩，从而导致领先用户。不太可能影响许多客户的模糊缺陷也可以纳入发行版，只要能够在以下情况下提供解决方法：确实会影响那些客户。默认情况下处于关闭状态的高度试验性功能的缺陷永远不会导致发行被延迟。