原文：So, you’ve released a broken package to PyPI. What do you do now?
第一步： 放轻松。这经常发生。
第二步： 要意识到，这就像电子邮件一样，一旦发出去，就没有办法撤回。
第三步： 发布一个新的，已修改的包。
近来，一些流行且重要的Python项目在发布的时候出现了一些问题。这些问题的性质和范围各异，并且对其进行谴责并不一定有建设性作用。但是，处理这些问题的方式，也就是从PyPI上删除包，最终造成这些包的维护者似乎没有意识到的一连串进一步的问题。所以我们今天说的是强调处理那些已经发布的受损软件包的最佳实践，并且希望可以避免这种事情的反复发生。
如上所述，有三个步骤来处理一个受损软件包。前两个步骤是必要的。你弄坏了一些东西，这可能令人尴尬且沮丧。人们可能会注意到。你的包越受欢迎，那么它们越有可能会，但这种事每个人都会遇到。根据它们实际上受损的程度，对于快速地解决它，你可能会感到很大的压力。受损包是很容易修复的，但在面对由于失误导致的问题时保持冷静，对于寻找合适的方式来解决这些问题是很重要的，并有助于防止损坏更多东西的反动步骤。
一个包发布到PyPI之后，它就已经在外流动。它存在于缓存服务器，代理和各种平台上，大部分是在那些你不能将其删除的地方。从PyPI中删除该软件包似乎是一个自然而然的解决方案，但它实际上会使问题变得更糟，而不是更好。从PyPI中删除该软件包不会帮助任何人运行带有显著包缓存的大型CI系统。它不会帮助任何人从这样一个高速缓存中进行到生产环境的持续部署。所有这些人仍然将使用受损包，并且如果在PyPI上该包不再可用，那么要调试其出处将会有进一步的挑战。你有关删除软件包的Tweet和IRC消息将会被人们忽视，但他们将不在社交网络渠道上关注你。
接受不能时光倒转或有效撤销受损包，会让你关于下一步该怎么做的选择限于思考第三步：如何将人们向前推进，让他们走出当前可能处于的境地。
在源代码级，如果没有立即可用的简单修复，那么最好的回应往往是将其恢复到受损之前。在该分支的当前状态之上（历史只会以一个方向移动），将其作为一个新的恢复进行提交。一旦你做到了这一点，并已经验证修复了受损包，那么是时候发布一个新版本了。你想用一个增量补丁版本作为新的版本，而不是重用现有的版本号。通过前滚版本，你将此修复推送给任何拥有一个配置管理系统的人，该配置管理系统进行与“pip install -U your-package”相同的工作。这也意味着，任何人使用你的包的无上限的要求来运行pip，将会得到新的，固定的版本，而不是旧的，坏了的版本。
该文与Monty Taylor共同完成。