何時/如何更新 Firebase Web SDK 版本號？

Question

當您初始化 Firebase 托管時，它會在生成的 index.html 文件的標頭中包含一條注釋：

<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>

我的問題與“根據需要”有關； 我看了文檔，沒有看到解釋。

可能這意味着它應該是顯而易見的——但是當您是初學者時，大多數事情都不是！

所以，為了讓我的問題更具體：

• 什么時候更新版本可能會導致 Firebase 網絡應用程序中斷？
• 相關地，如果一個應用程序正在運行，並且很長時間沒有更新（許多版本/年），該應用程序是否仍能正常運行？ 或者如果不保持最新狀態它會壞掉嗎？
• “根據需要”是否意味着“根據需要[訪問新功能]”？
• 最后，是否暗示這些更改應該手動實施——通過定期查找最新的 Firebase 版本，並在 index.html 中輸入新版本號——或者是否有某種自動“保持最新”的工作流程/隱含的工具/約定？

我意識到上面有很多子問題，但它們都是為了澄清“根據需要更新”，所以我認為它們屬於同一個地方。

我希望任何答案都能幫助其他初學者了解何時適合更新應用程序所依賴的服務這一更大的問題。 謝謝。

Answer 1

Firebase 遵循所謂的語義版本控制 (SemVer) 規則。

來自semver.org ：

給定版本號 MAJOR.MINOR.PATCH，遞增：

進行不兼容的 API 更改時的主要版本，

以向后兼容的方式添加功能時的 MINOR 版本，以及

進行向后兼容的錯誤修復時的 PATCH 版本。

這意味着 API 保證在您的情況下在次要版本 (7.x) 內保持兼容，但可能會在主要版本 (8.0) 中進行重大更改。 這意味着次要版本 (7.x) 用於修復問題，有時還會添加不破壞現有行為的次要功能。

有了這些知識，讓我們看看是否可以回答您的問題：

什么時候更新版本可能會導致 Firebase 網絡應用程序中斷？

在同一主要版本（7.x，例如 7.5.2 -> 7.5.3，或 7.5.2 -> 7.6.0）內更新應該不會破壞您的應用程序。 有一些例外，例如當您的代碼依賴於已修復的錯誤行為時，或者當發布中存在錯誤時。 后者通常會由 Firebase 團隊盡快修復，而您通常希望回滾到以前的版本並在前一種情況下更新您的代碼。

相關地，如果一個應用程序正在運行，並且很長時間沒有更新（許多版本/年），該應用程序是否仍能正常運行？ 或者如果不保持最新狀態它會壞掉嗎？

版本發布后，將保持不變。 因此，您的應用程序將保持您創建時的狀態。

“根據需要”是否意味着“根據需要[訪問新功能]”？

升級的兩個主要原因：

1. 訪問新功能。

   這是升級的最明顯原因，因為它允許您將新功能從 Firebase 添加到您的應用程序。 最常見的是這個

2. 訪問錯誤修復。

   在您使用的庫版本中可能會發現錯誤，其中一些錯誤可能是安全漏洞。 在這種情況下，不更新到更新的版本意味着您的應用程序中存在已知的安全漏洞。 這里要意識到的關鍵是已知部分：大多數黑客搜索具有已知漏洞的應用程序，而不是試圖尋找新的漏洞。

最后，是否暗示這些更改應該手動實施——通過定期查找最新的 Firebase 版本，並在 index.html 中輸入新版本號——或者是否有某種自動“保持最新”的工作流程/隱含的工具/約定？

如果您使用工具來構建/打包您的網站，那通常有一種方法可以自動引入新版本。

許多開發人員將此類工具配置為在每次構建時自動引入新補丁 (7.5.x)，而有些甚至引入新的次要版本 (7.xx)。 但也有一種觀點傾向於硬編碼確切的版本號，並且只通過定期檢查手動升級。

無論哪種方式，都需要進行新構建才能升級，即使在這種情況下也是如此。 這是一件好事™️，因為您最不想看到的是當 Firebase 意外發布帶有錯誤的新版本時您的應用程序在生產中中斷（這種情況很少見，但確實發生過）。 通過在構建過程中只包含一個新版本，您可以降低這種風險，尤其是當您在構建過程中運行應用程序功能的自動化測試時。

這里沒有正確或錯誤的答案，因為任何一個都可以正常工作。 這真的取決於你自己的喜好。