Overview of Firebase's policies for changes and versioning
Stay organized with collections
Save and categorize content based on your preferences.
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.
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.
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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],[],[],[],null,["**Last updated: September 30, 2023**\n\nFirebase is a suite of products and services that expose their functionality via\nSDKs, APIs, and tooling --- these are referred to in this document as **Firebase\ncomponents**.\n\nWe've provided the following set of documents to help you understand how\nFirebase makes and communicates changes to these components, especially our\nversioned components.\n\n- **Overview of Firebase's policies** (this page) \n\n *Learn about our philosophy, understand the scope of our policies, and find\n a high-level summary of our policies.*\n\n- [**Firebase's policies for introducing changes and communicating those changes**](/policies/changes-to-firebase/introducing-and-communicating-changes) \n\n *Learn about each type of change that Firebase can make as well as the\n timelines and methods of communication for changes.*\n\n- [**Firebase's policies for versioning our versioned components and maintaining them**](/policies/changes-to-firebase/versioning-and-maintenance) \n\n *Learn about the versioning schemes that Firebase uses and our policies for\n maintaining previous versions.*\n\n**Philosophy about changes to Firebase components**\n\nDevelopers need a clear path and plan to update their apps and workflows,\nwhether to take advantage of the latest APIs, features, and functionality, or to\naddress issues affecting their app from a previous version. Firebase aims to\nmake these transitions as predictable and straightforward as possible to\nminimize the effort required by developers. And we strive to give developers\nenough time to plan and roll out necessary changes to their apps.\n\nFirebase recognizes that more substantial changes in Firebase components, like\ndeprecations and breaking changes, can be frustrating and disruptive to\ndevelopers. However, we also recognize that these types of changes are sometimes\nnecessary to 1) innovate, 2) stay current with new best practices, languages,\nand platform provider updates, 3) change dependencies, 4) address critical\nvulnerabilities, and 5) ensure Firebase devotes resources to those features and\ncomponents which appear to be most useful for our developer community.\n\nWith this philosophy in mind, Firebase will strive to do the following:\n\n- Minimize the number of breaking changes and the impact of those changes.\n- Communicate breaking changes publicly with sufficient warning.\n- 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.\n- 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.\n- Follow the policies described in this document.\n\n**Scope of these policies**\n\nThe policies described in this document apply to the Firebase components that\nhave been released to General Availability (GA).\n\nAlso, since Firebase is composed of both versioned and unversioned Firebase\ncomponents, this document applies to both.\n\n- **Versioned Firebase components** : These include the product SDKs, APIs, and versioned tooling (like the Firebase CLI and the Firebase Local Emulator Suite).\n- **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.\n\nLearn more about how and when Firebase handles\n[versioning of Firebase's versioned components](/policies/changes-to-firebase/versioning-and-maintenance).\n\nIn some cases, Firebase services are backend or infrastructure tooling which\nsupport other Google products or services and are not surfaced to any external\n(non-Google) customer or user as a service or product per se; in those cases and\nto that extent they are not externally-facing products and are not subject to\nthis policy.\n\n**High-level summary of policies** **The following information is a\n| *high-level summary*.** \n| To fully understand the nuances and answer questions about Firebase's policies, we strongly recommend reviewing all the documents provided about our policies for making and communicating changes (see list at top of this page).\n\nThe following is a *high-level summary* of the most frequently sought\ninformation about our policies:\n\n- When Firebase\n [deprecates](/policies/changes-to-firebase/introducing-and-communicating-changes#deprecations)\n a product or feature, it is still available and functional through the\n deprecated phase. We strive to give developers enough time to migrate to a\n replacement before introducing the breaking change: for products, at least\n 12 months; for features or elements, *usually* at least 6 months.\n\n For detailed information about timelines and information that we provide\n at the time of deprecation and before we introduce the associated breaking\n change, see\n [Understanding the deprecated phase](/policies/changes-to-firebase/introducing-and-communicating-changes#deprecated-phase).\n- For our Firebase SDKs and versioned tooling, we aim to introduce\n [breaking changes](/policies/changes-to-firebase/introducing-and-communicating-changes#breaking-changes)\n only twice per year at most. These breaking changes will be in a major\n versioning (as advised by [semver](http://semver.org)).\n\n- Firebase communicates deprecations and upcoming breaking changes in\n emails to project Owners, in applicable developer interfaces (console,\n CLI, documentation, etc.), and in our release notes. For detailed\n information about these methods of communication, see\n [Communicating changes publicly](/policies/changes-to-firebase/introducing-and-communicating-changes#communicating-changes)."]]
