使用分支或单独的存储库来维护不向后兼容的多个代码版本的正确方法是什么？

Question

我为Revit编写附加模块。这些附加模块取决于Revit API库。这些库随Revit的每个新版本(2018、2019、2020等)而变化。不幸的是，它们不是向后兼容的，所以我不能使用2018年和2020年的插件。这意味着我为2018年、2019年和2020年分别维护了我自己的代码存储库。我目前正在使用拉取请求，因此如果我在2018年做出更改，我可以将其转移到2019和2020年。问题是，当遇到请求时，它会更新我的2019/2020库，以引用2018年的库。然后，我必须返回并确保它引用了正确的库。

每次当我需要将更改推送到其他版本时，我应该如何避免这个问题？

Answer 1

是否确实不能在Revit 2020中使用2018附加模块？

在许多情况下，如果不是大多数情况下，情况恰恰相反。

通常，您也可以在更高版本中使用为Revit的早期版本编译的附加模块。

如果调用的Revit API功能在不同版本之间发生了更改，则可以通过编译早期版本的Revit并添加.NET运行时功能来处理此问题，以便在运行时检查是调用旧版本的Revit API还是调用新版本的Revit API。更改的调用可以在运行时为新版本动态更新。

有关完整的实现示例，请查看The Building Coder Multi-Version Add-in。

尽管如此，我仍然完全同意您的问题本身；在许多情况下，您需要为每个Revit版本提供一个单独的干净更新版本的附加模块，以避免复杂性并增强代码可读性。为此，我完全同意rel关于为每个版本维护一个单独的分支并将更新合并到其他分支中的观点。

Answer 2

我写的一个插件也有同样的问题。由于API更改，我必须根据与外接程序相关联的年份制作不同的版本。我为每个版本设置了一个独立项目的解决方案，并共享代码和库，以减少重复代码的数量。不幸的是，我是在创建第二个版本之后设置的，所以并不是所有的代码都被正确地细分了。但是，这应该会让您了解如何设置它。您可以在github存储库中看到这一点：CreateSheets。

请注意，虽然这确实减少了代码量，但它需要一些额外的工作，因为对共享代码的更改需要考虑每个版本。