Last updated: September 30, 2023
Firebase is comprised of both versioned and unversioned Firebase components. This document applies to the following versioned components:
Learn about Firebase's policies for maintaining previous versions at the bottom of this page.
Firebase SDKs and versioned tooling
This section applies to Firebase SDKs and versioned tooling, including the Firebase CLI and the Firebase Local Emulator Suite.
Versioning system for SDKs and versioned tooling
Firebase SDKs and versioned tooling use semantic versioning (also known as "semver"). This versioning system allows developers to choose when to perform the necessary work to update their apps and development environment to the latest version.
Changes like bug fixes and new features are usually backwards-compatible, so Firebase introduces them within minor versions (and patch versions for backwards-compatible bug fixes).
Breaking changes are not backwards-compatible, so Firebase introduces them only in major versions.
Developers can remain on an older major version to avoid those breaking changes and the associated work required to accommodate them. Note, though, that the older version will be in the end-of-maintenance (EoM) phase, so Firebase recommends updating to the latest version, but there's no requirement to update.
Variation in versions for client SDKs
Firebase supports many platforms, like Android and JavaScript. Each supported platform has at least one SDK per product, as well as additional infrastructure-related SDKs. The major version number for each supported platform can vary. For example, the SDKs for Apple platforms may be at major version 10, while the SDKs for JavaScript may be at major version 9.
The SDKs for Apple platforms, JavaScript, Unity, and C++ all share a single version number across the different product SDKs. For example, in April 2023, all product SDKs for Apple platforms were at the same version 10.9.0.
The SDKs for Android and Flutter can have a different version number for each product SDK.
- To simplify the experience for Android developers, the Firebase SDKs for Android use the bill of materials (BoM) technology where each Firebase Android BoM release contains compatible versions of Firebase's product SDKs for Android.
Developers can find the latest versions for Firebase SDKs and versioned tooling in the Firebase "general" release notes.
Release cadence for SDKs and versioned tooling
See the applicable section to learn about the release cadence for the following:
Release cadence for Firebase SDKs (client)
Firebase client SDKs have a regular and predictable release schedule that makes it easier for developers to plan their integrations or updates accordingly and to budget their time and resources more effectively.
| Cadence | Possible release type (versioning) | Changes that the release can contain |
|---|---|---|
| Every 3 weeks | Patch | Changes and bug fixes that are backwards-compatible with our APIs and tooling |
| Minor | New features, new deprecations, and changes and bug fixes that are backwards-compatible with our APIs and tooling | |
| Two times per year (usually May/June and Oct/Nov) |
Major | Removal of deprecated components (following the deprecation policy), other breaking changes, new features, new deprecations, and changes and bug fixes that are backwards-compatible with our APIs and tooling |
Whenever possible, Firebase SDKs follow the scheduled release cadence. However, the following situations may result in a different cadence:
If there are no changes, then a Firebase SDK isn't obligated to release at each cadence instance.
If there's a highly important bug fix or security vulnerability fix that can't wait until the next scheduled release, then a Firebase SDK can release out-of-band. An out-of-band release is usually only a patch release.
If there's a special circumstance, then a Firebase SDK can delay its release. These special circumstances could include: the release isn't ready, there's a high-priority bug that's still being fixed, there's a holiday or other event that disrupts the release cadence, or the timing of the release isn't aligned with business needs.
Release cadence for Firebase Admin SDKs
Releases of the Firebase Admin SDKs do not have a standard release cadence. However, Firebase generally tries to introduce any breaking changes only two times per year (May/June or Oct/Nov).
Release cadence for versioned tooling
Releases of versioned tooling, like the Firebase CLI and the Firebase Local Emulator Suite, do not have a standard release cadence. However, Firebase generally tries to introduce any breaking changes only two times per year (May/June or Oct/Nov).
Firebase REST and gRPC APIs
This section applies to Firebase REST APIs and gRPC APIs.
Versioning system for REST and gRPC APIs
Firebase REST and gRPC APIs are built on the Google Cloud Service Infrastructure, and Firebase applies its principles. Currently, the Firebase REST and gRPC APIs mostly follow the "release-based" versioning model described in the public Google Cloud API versioning guidelines
These guidelines allow each API surface to have multiple releases in alpha and beta stages, but only one stable release. For example, the following are all valid API versions for a given API surface: v1alpha1, v1beta1, v1beta2, and v1.
Variation in versions for REST and gRPC APIs
For some API surfaces, you might see both v1beta1 and v1beta versions. This is because the "channel-based" versioning model was the recommended model when the API was launched, and Firebase used it.
Here are some examples:
Cloud Firestore uses release-based versioning:
App Check uses channel-based versioning:
Release cadence for REST and gRPC APIs
Firebase REST and gRPC APIs do not have a standard release cadence. However, we generally try to introduce any breaking changes only two times per year (May/June or Oct/Nov).
Maintaining previous versions
Firebase only supports the most recent major version of its versioned components. Bug fixes for critical issues, such as security vulnerabilities or performance degradations, are only released in the current major version and are not backported to older versions. These older versions are in the end-of-maintenance (EoM) phase.