When/how 更新 Firebase web SDK 版本号？
When/how to update Firebase web SDK version number?
当您初始化 Firebase 托管时，它会在生成的 index.html 文件的 header 中包含一条注释：
<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>
我的问题与 "as needed;" 有关，我查看了文档，但没有看到任何解释。
可能这意味着它应该是显而易见的 -- 但是当您是初学者时，大多数事情都不是！
所以，为了让我的问题更具体：
- 什么时候更新版本可能会导致 Firebase 网络应用程序中断？
- 相关的，如果一个应用程序正在运行，并且很长时间没有更新
时间（许多 versions/years），应用程序是否仍能正常运行？或者如果不保持最新状态它会坏掉吗？
- "as needed" 是否意味着 "as needed [for access to new features]"？
- 最后，是否暗示应该实施这些更改
手动——通过定期查找最新的 Firebase 版本
是，并在 index.html 中输入一个新的版本号——或者是否有一些
一种自动 "stay current" workflow/tooling/convention 即
暗示？
我知道上面有很多sub-questions，但它们都是为了澄清"update as needed,"，所以我认为它们属于同一个地方。
我希望任何答案都能帮助其他初学者理解什么时候更新应用程序所依赖的服务是合适的这个更大的问题！谢谢。
Firebase 遵循所谓的语义版本控制 (SemVer) 规则。
来自semver.org：
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
这意味着 API 保证在您的情况下在次要版本 (7.x) 中保持兼容，但可能会在主要版本 (8.0) 中进行重大更改。这意味着次要版本 (7.x) 用于修复问题，有时还会添加不破坏现有行为的次要功能。
有了这些知识，让我们看看能否回答您的问题：
When might updating the version make a Firebase web app break?
在同一主要版本（7.x，例如 7.5.2 -> 7.5.3，或 7.5.2 -> 7.6.0）内更新应该不会破坏您的应用。有一些例外，例如当您的代码依赖于已修复的错误行为时，或者当发布中存在错误时。后者通常会由 Firebase 团队尽快修复，而在前一种情况下，您通常会希望回滚到以前的版本并更新您的代码。
Relatedly, if an app is working, and one does not update for a long time (many versions/years), does the app remain functioning? Or will it break if not kept current?
版本发布后，将保持不变。因此，您的应用将保持您创建时的状态。
Does "as needed" imply "as needed [for access to new features]"?
升级的两个主要原因：
访问新功能。
这是升级的最明显原因，因为它允许您将 Firebase 的新功能添加到您的应用程序。最常见的是这个
访问错误修复程序。
在您使用的库版本中可能会发现错误，其中一些错误可能是安全漏洞。在这种情况下，不更新到更新的版本意味着您的应用中将存在 已知 安全漏洞。这里要意识到的关键是 已知 部分：大多数黑客搜索具有已知漏洞的应用程序，而不是试图寻找新的漏洞。
Finally, is it implied that these changes should be implemented manually -- by regularly looking up what the latest Firebase version is, and typing a new version number in index.html -- or is there some kind of automatic "stay current" workflow/tooling/convention that is implied?
如果您使用工具 build/pack 您的网站，通常可以自动引入新版本。
许多开发人员将此类工具配置为在每次构建时自动引入新补丁 (7.5.x)，而有些甚至引入新的次要版本 (7.x.x)。但也有一种观点倾向于硬编码确切的版本号，仅通过定期检查手动升级。
无论哪种方式，都需要重新构建才能升级，即使在这种情况下也是如此。这是一件好事™️，因为您最不想看到的是当 Firebase 意外发布带有错误的新版本时您的应用程序在生产中中断（这种情况很少见，但确实发生过）。通过在您的构建过程中只包含一个新版本，您可以降低这种风险，特别是如果您 运行 在构建过程中自动测试您的应用程序的功能。
这里没有正确或错误的答案，因为任何一个都可以正常工作。完全看你自己的喜好了。
当您初始化 Firebase 托管时，它会在生成的 index.html 文件的 header 中包含一条注释：
<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>
我的问题与 "as needed;" 有关，我查看了文档，但没有看到任何解释。
可能这意味着它应该是显而易见的 -- 但是当您是初学者时，大多数事情都不是！
所以，为了让我的问题更具体：
- 什么时候更新版本可能会导致 Firebase 网络应用程序中断？
- 相关的，如果一个应用程序正在运行，并且很长时间没有更新 时间（许多 versions/years），应用程序是否仍能正常运行？或者如果不保持最新状态它会坏掉吗？
- "as needed" 是否意味着 "as needed [for access to new features]"？
- 最后，是否暗示应该实施这些更改 手动——通过定期查找最新的 Firebase 版本 是，并在 index.html 中输入一个新的版本号——或者是否有一些 一种自动 "stay current" workflow/tooling/convention 即 暗示？
我知道上面有很多sub-questions，但它们都是为了澄清"update as needed,"，所以我认为它们属于同一个地方。
我希望任何答案都能帮助其他初学者理解什么时候更新应用程序所依赖的服务是合适的这个更大的问题！谢谢。
Firebase 遵循所谓的语义版本控制 (SemVer) 规则。
来自semver.org：
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
这意味着 API 保证在您的情况下在次要版本 (7.x) 中保持兼容，但可能会在主要版本 (8.0) 中进行重大更改。这意味着次要版本 (7.x) 用于修复问题，有时还会添加不破坏现有行为的次要功能。
有了这些知识，让我们看看能否回答您的问题：
When might updating the version make a Firebase web app break?
在同一主要版本（7.x，例如 7.5.2 -> 7.5.3，或 7.5.2 -> 7.6.0）内更新应该不会破坏您的应用。有一些例外，例如当您的代码依赖于已修复的错误行为时，或者当发布中存在错误时。后者通常会由 Firebase 团队尽快修复，而在前一种情况下，您通常会希望回滚到以前的版本并更新您的代码。
Relatedly, if an app is working, and one does not update for a long time (many versions/years), does the app remain functioning? Or will it break if not kept current?
版本发布后，将保持不变。因此，您的应用将保持您创建时的状态。
Does "as needed" imply "as needed [for access to new features]"?
升级的两个主要原因：
访问新功能。
这是升级的最明显原因，因为它允许您将 Firebase 的新功能添加到您的应用程序。最常见的是这个
访问错误修复程序。
在您使用的库版本中可能会发现错误，其中一些错误可能是安全漏洞。在这种情况下，不更新到更新的版本意味着您的应用中将存在 已知 安全漏洞。这里要意识到的关键是 已知 部分：大多数黑客搜索具有已知漏洞的应用程序，而不是试图寻找新的漏洞。
Finally, is it implied that these changes should be implemented manually -- by regularly looking up what the latest Firebase version is, and typing a new version number in index.html -- or is there some kind of automatic "stay current" workflow/tooling/convention that is implied?
如果您使用工具 build/pack 您的网站，通常可以自动引入新版本。
许多开发人员将此类工具配置为在每次构建时自动引入新补丁 (7.5.x)，而有些甚至引入新的次要版本 (7.x.x)。但也有一种观点倾向于硬编码确切的版本号，仅通过定期检查手动升级。
无论哪种方式，都需要重新构建才能升级，即使在这种情况下也是如此。这是一件好事™️，因为您最不想看到的是当 Firebase 意外发布带有错误的新版本时您的应用程序在生产中中断（这种情况很少见，但确实发生过）。通过在您的构建过程中只包含一个新版本，您可以降低这种风险，特别是如果您 运行 在构建过程中自动测试您的应用程序的功能。
这里没有正确或错误的答案，因为任何一个都可以正常工作。完全看你自己的喜好了。