我正在維護一個通過包管理器（NuGet、Maven、NPM 等……沒關系）分發的庫/包，并且我的新包意外破壞了向后兼容性的次數太多了。
例如，有一次我無意中向方法添加了一個引數，卻沒有意識到它破壞了向后兼容性。
你如何確保你的包向后兼容？你有任何自動化測驗嗎？如果有，是什么樣的？或者你只是依賴代碼審查員？.Net 的答案會很棒，但也非常感謝任何語言的答案。
謝謝
uj5u.com熱心網友回復：
Roslyn 團隊創建了一個有幫助的代碼分析器。GitHub 上有關于如何使用它的說明。
基本上，您將Microsoft.CodeAnalysis.PublicApiAnalyzers 包添加到您的專案中。如果您手動編輯您的專案檔案/msbuild 檔案，請務必添加PrivateAssets="all"到PackageReference.
然后，當您構建專案時，如果任何公共 API 未在PublicAPI.Shipped.txt或PublicAPI.Unshipped.txt檔案中定義，分析器就會抱怨。這可以幫助您檢測何時有人添加了新 API，因此代碼審查員可以決定該 API 是否是支持應支持的 API。如果在代碼中找不到在其中一個文本檔案中定義的 API，則還有一條規則可以投訴。這告訴每個人 API 已損壞。包中還有一些其他分析器/規則，它們有助于保持 API 穩定并提高包消費者的 API 質量。
添加新 API 時，會通過代碼修復將新 API 添加到PublicAPI.Unshipped.txt檔案中。你如何使用PublicAPI.Unshipped.txt，并PublicAPI.Shipped.txt是你的，但我們的團隊由未發貨我們發布包nuget.org后，將所有內容發貨。這意味著如果拉取請求洗掉或更改了 中的 API PublicAPI.Unshipped.txt，這不是破壞性更改，因為該 API 從未在 nuget.org 上的包中可用。
我的團隊尚未圍繞拉取請求中的公共 API 更改實作任何自動化。但是，根據您的 CI 管道的復雜程度，您還可以對公共 API 更改實施更嚴格的政策。例如，使用 GitHub webhooks，您可以：
- 當 PR 獲得“PublicAPI:changed”標簽時，使用 GitHub Checks API 阻止 PR 被合并。如果標簽被移除，則取消阻止 PR 被合并。
- 當帶有“PublicAPI:changed”標簽的 PR 獲得“PublicAPI:approved”標簽時，使用 GitHub Checks 解除對 PR 合并的阻止。同樣，如果批準的標簽被洗掉，但更改的標簽保留，再次阻止 PR 被合并。
- 創建 PR 或添加新提交時，檢查 PR 目標分支之間的差異，如果有任何
PublicAPI.[Unshipped|Shipped].txt檔案更改，則自動添加“PublicApi:changed”標簽。如果 PR 已具有“PublicAPI:changed”標簽，但 PR 不再包含任何PublicAPI.*.txt更改，則移除“PublicAPI:changed”標簽。- 在推送新提交時是否洗掉“PublicAPI:approved”標簽由您決定。這取決于擁有已批準 API 的 PR 的人進行另一次公共 API 更改并試圖在沒有其他公共 API 批準的情況下潛入的頻率/可能性。另一方面，如果 PR 需要一個與公共 API 無關的小修復，再次請求某人批準公共 API 可能會很煩人。
無論如何，這只是一個想法。到目前為止，我們只是手動通知 PR 包含公共 API txt 檔案更改時，并根據需要 ping 團隊中的其他人進行審查。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/367940.html