Last updated: September 30, 2023
Firebase is a suite of products and services that expose their functionality via
SDKs, APIs, and tooling ? these are referred to in this document as
Firebase
components
.
We've provided the following set of documents to help you understand how
Firebase makes and communicates changes to these components, especially our
versioned components.
Philosophy about changes to Firebase components
Developers need a clear path and plan to update their apps and workflows,
whether to take advantage of the latest APIs, features, and functionality, or to
address issues affecting their app from a previous version. Firebase aims to
make these transitions as predictable and straightforward as possible to
minimize the effort required by developers. And we strive to give developers
enough time to plan and roll out necessary changes to their apps.
Firebase recognizes that more substantial changes in Firebase components, like
deprecations and breaking changes, can be frustrating and disruptive to
developers. However, we also recognize that these types of changes are sometimes
necessary to 1) innovate, 2) stay current with new best practices, languages,
and platform provider updates, 3) change dependencies, 4) address critical
vulnerabilities, and 5) ensure Firebase devotes resources to those features and
components which appear to be most useful for our developer community.
With this philosophy in mind, Firebase will strive to do the following:
- Minimize the number of breaking changes and the impact of those changes.
- Communicate breaking changes publicly with sufficient warning.
- Provide clear documentation to help developers understand if they are
impacted, what the extent of the impact is, and to assist them with
migration to alternatives.
- Give developers ample time to understand, design, build, test, and
deploy necessary changes to all their production apps, without undue
interruption to their ongoing development roadmap.
- Follow the policies described in this document.
Scope of these policies
The policies described in this document apply to the Firebase components that
have been released to General Availability (GA).
Also, since Firebase is composed of both versioned and unversioned Firebase
components, this document applies to both.
- Versioned Firebase components
: These include the product SDKs, APIs, and
versioned tooling (like the Firebase CLI and the
Firebase Local Emulator Suite).
- Unversioned Firebase components
: These include the Firebase web
console, products or features that depend on unversioned backend services
(such as Firebase Hosting or a database region), and Firebase integrations
with other Google services, third-party services, IDEs, etc.
Learn more about how and when Firebase handles
versioning of Firebase's versioned components
.
In some cases, Firebase services are backend or infrastructure tooling which
support other Google products or services and are not surfaced to any external
(non-Google) customer or user as a service or product per se; in those cases and
to that extent they are not externally-facing products and are not subject to
this policy.
High-level summary of policies
The following is a
high-level summary
of the most frequently sought
information about our policies:
When Firebase
deprecates
a product or feature, it is still available and functional through the
deprecated phase. We strive to give developers enough time to migrate to a
replacement before introducing the breaking change: for products, at least
12 months; for features or elements,
usually
at least 6 months.
For detailed information about timelines and information that we provide
at the time of deprecation and before we introduce the associated breaking
change, see
Understanding the deprecated phase
.
For our Firebase SDKs and versioned tooling, we aim to introduce
breaking changes
only twice per year at most. These breaking changes will be in a major
versioning (as advised by
semver
).
Firebase communicates deprecations and upcoming breaking changes in
emails to project Owners, in applicable developer interfaces (console,
CLI, documentation, etc.), and in our release notes. For detailed
information about these methods of communication, see
Communicating changes publicly
.