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另一個應用程序（複製文件夾），將所有的公共庫出來的應用程序，並保持只有可能會改變的類以及在應用程序中需要向後兼容性支持。