When/how to update Firebase web SDK version number? - firebase

Question

When you initialize Firebase hosting, it includes a comment in the header of the index.html file that is generated:
<!-- update the version number as needed -->
<script defer src="/__/firebase/7.5.2/firebase-app.js"></script>
My question has to do with "as needed;" I looked at the docs, and didn't see an explanation.
Probably this means it is supposed to be obvious -- but when you're a beginner, most things aren't!
So, to make my question more concrete:
When might updating the version make a Firebase web app break?
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]"?
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?
I realize that there are a number of sub-questions above, but they are all intended to be clarifications of "update as needed," so I think they belong in the same place.
I hope any answers will help other beginners understand the larger issue of when it is appropriate to update the services an app depends upon! Thanks.

Answer 1

Firebase follows what is known as semantic versioning (SemVer) rules.
From 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.
That means that the API is guaranteed to stay compatible within minor version (7.x) in your case, but breaking changes may be made in major version (8.0). This means that minor versions (7.x) are used to fix problems, and sometimes add minor features that don't break existing behavior.
With that knowledge, let's see if we can answer your questions:
When might updating the version make a Firebase web app break?
Updating within the same major version (7.x, e.g. 7.5.2 -> 7.5.3, or 7.5.2 -> 7.6.0) should not break your app. There are some exceptions, such as when your code depends on buggy behavior that was fixed, or when there is a mistake in the release. The latter will typically be fixed by the Firebase team as soon as possible, while you'll typically want to roll back to the previous version and update your code in the former case.
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?
Once a version is published, it remains unmodified. So your app will stay working the way it did when you made it.
Does "as needed" imply "as needed [for access to new features]"?
Two main reasons for upgrading:
To get access to new features.
This is the most obvious reason to upgrade, as it allows you to add new functionality from Firebase to your app. Most often this
To get access to bug fixes.
Bugs may be discovered in the library version you use, and some of those bugs may be security holes. In that case, not updating to a more recent version means that you'll have a known security vulnerability in your app. Key to realize here is the known part: most hackers search for apps with known vulnerabilities, instead of trying to find new vulnerabilities.
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?
If you use a tool to build/pack your website, that typically has a way to automatically pull in new versions.
Many developers configure such a tool to automatically pull in new patches (7.5.x) upon every build, while some even pull in new minor release (7.x.x). But there's also a school of thought that prefers to hard-code the exact version number and only upgrade manually by regularly checking.
Either way, it's required to make a new build to upgrade, even in this case. That's a Good Thing™️, as the last thing you want is that your app breaks in production when Firebase accidentally releases a new version with a bug (a rare occurrence, but it has happened). By only including a new version in your build process, you reduce this risk, especially if you run automated tests of your app's functionality as part of the build.
There's no right or wrong answer here, as either can work just fine. It's really up to your own preference.