内部项目：稳定发布与否？

Question

假设您在一家大中型软件公司工作，该公司拥有许多独立开发的项目（独立编码员），但相互依赖（依赖代码）。

如果由您决定，您是否会确保每个项目都生成稳定的分支，以便其他项目可以更可靠地使用这些分支，或者您是否鼓励项目直接使用其他项目中的最新可用代码？

稳定版本的优势对我来说很明显 - 您的依赖项更有可能像宣传的那样工作。然而，我还可以看到避免稳定版本的一些好处 - 每个项目的工作量都要少一点，而且你可以对影响每个人的bug做出快速反应，因为你的代码总是会自动更新。例如，假设在一个内部库中的时间戳X处存在微妙的安全漏洞 - 在该代码被广泛使用之前可能不会被注意到。如果您正在使用稳定版本分支，则必须让其他所有项目修改其依赖项以实现安全修复。如果没有发布分支，则会在所有其他项目的下一个版本中立即获取修复程序。

如果有人对两种选择都有行业经验，我特别感兴趣。

Answer 1

与往常一样，每个选项都有利弊。

使用分支可能更稳定，但当您需要更新到更新的分支时需要更多维护。它还要求他们的开发团队在分支与主干合并时花费额外的时间。

另一方面，使用主干可能会迫使您处理其他人的错误并编写凌乱的变通代码来绕过它。如果你得到奇怪的OutOfMemory / Performance问题，这些问题无法固定到特定的库（或你自己的代码），它可能会变得特别混乱。请记住，这不是您的代码，您可能没有人力来帮助他们进行质量保证工作......

所以我想最后一句话就是它取决于它。我建议考虑这些因素：

1. 您正在使用的API会改变吗？
2. 处理“干净的代码”是否很重要，或者你是否可以让自己弄乱其他人的错误？
3. 应用程序使用“尖端”版本的库是否至关重要？

作为旁注，从经验来看，我可以告诉你，我们的一个程序员错过了几个晚上的睡眠，因为他在分支机构工作，升级到更新的分支机构改变了整个API和逻辑。 ：）

HTH

Answer 2

认为它确实打破了软件的关键任务。如果你可以忍受轻微崩溃，也许一些数据损坏并且很容易推送新版本，那么运行不稳定的代码可能是首选。现在，如果生命或声誉依赖于一切正常工作，或者推动新构建是一个主要过程，那么稳定的测试版本是唯一的出路。

Answer 3

在其他项目中，在我看来，您提出的问题通过拥有安全分支来解决。例如。 Debian包。这样，您将继续在项目中使用稳定分支。由于您提到的原因，测试/在制品分支存在太大的风险。