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.
Overview of Firebase's policies (this page)
Learn about our philosophy, understand the scope of our policies, and find a high-level summary of our policies.Firebase's policies for introducing changes and communicating those changes
Learn about each type of change that Firebase can make as well as the timelines and methods of communication for changes.Firebase's policies for versioning our versioned components and maintaining them
Learn about the versioning schemes that Firebase uses and our policies for maintaining previous versions.
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.