DRF 版本控制的最佳实践 - 复制整个文件夹？还是子类以前的版本？

Question

基于this question，尤其是this answer，创建 v2、v3 等的最可持续的方式是什么 - 大多数时候，每个版本都会对之前的版本进行增量更改。大多数端点保持不变，大多数字段保持不变。

选项 1：复制 v1 文件夹，重做内部引用以确保代码已更新，然后对其进行更改。这使每个版本都保持独立。如果出现错误，您可以在所有版本中修复它。版本干净，依赖项更易于管理。但是，例如，在 v30 之后，您最终会得到大量重复的代码。

选项 2：创建 v2 文件夹，并使 v2 类成为 v1 类的子类，提供基本功能，然后添加您的更改。这促进了代码重用，但会变得非常快速，例如。当您拥有超过 30 个版本时，跟踪更改/修复错误。

任何流行的最佳实践，优点/缺点？

Answer 1

您的选项 2 将在几个版本中变成选项 1。

在我看来有两种情况：

1 个案例：您有传统的主要是 CRUD API，然后我建议您查看 this post，它显示了一种通过序列化器在版本之间创建转换的方法。

2 案例：您的 API 更多的是关于算法、逻辑和数据处理 - 然后您可以使用选项 1 - 在 DRF 中创建另一个应用程序（复制文件夹），将所有常用库移出该应用程序并仅保留可能更改且需要在应用程序中提供向后兼容性支持的类。