**Last updated: September 30, 2023**

Firebase is comprised of both versioned and unversioned Firebase components.
This document applies to the following versioned components:

- [Firebase SDKs and versioned tooling](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#sdks-and-versioned-tooling)
- [Firebase REST and gRPC APIs](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#rest-and-grpc-apis)

Learn about Firebase's policies for
[maintaining previous versions](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#maintaining-previous-versions)
at the bottom of this page.

<br />


*** ** * ** ***

<br />

## **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](http://semver.org) (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).**

  > [!NOTE]
  > **Example:** The Apple platforms SDK [v10.8.0](https://firebase.google.com/support/release-notes/ios.md.txt#version_1080_-_april_11_2023) contains one bug fix, three small backwards-compatible changes, and three new features.

- **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](https://firebase.google.com/policies/changes-to-firebase/introducing-and-communicating-changes.md.txt#end-of-maintenance),
  so Firebase recommends updating to the latest version, but there's no
  *requirement* to update.

  > [!NOTE]
  > **Example:** The Apple platforms SDK [v9.5.0](https://firebase.google.com/support/release-notes/ios.md.txt#version_950_-_august_23_2022) is backwards-compatible with [v9.4.1](https://firebase.google.com/support/release-notes/ios.md.txt#version_941_-_august_8_2022). However, [v10.0.0](https://firebase.google.com/support/release-notes/ios.md.txt#version_1000_-_october_10_2022) is not backwards-compatible with v9.5.0 or v9.4.1 because v10.0.0 introduces a breaking change (the minimum supported iOS versions were updated).
  >
  > Even with the release of v10, developers can continue using v9. Note,
  > though, that v9 will be in the
  > [end-of-maintenance (EoM) phase](https://firebase.google.com/policies/changes-to-firebase/introducing-and-communicating-changes.md.txt#end-of-maintenance),
  > so Firebase recommends updating to the latest version, but there's no
  > *requirement* to update to v10.

### 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](https://firebase.google.com/docs/android/learn-more.md.txt#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](https://firebase.google.com/support/releases.md.txt).

### Release cadence for SDKs and versioned tooling

See the applicable section to learn about the release cadence for the
following:

- [Firebase SDKs (client)](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#release-cadence-client-sdks)

- [Firebase Admin SDKs](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#release-cadence-admin-sdks)

- [Firebase versioned tooling](https://firebase.google.com/policies/changes-to-firebase/versioning-and-maintenance.md.txt#release-cadence-versioned-tooling)

#### 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 |
| Every 3 weeks | 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](https://firebase.google.com/policies/changes-to-firebase/introducing-and-communicating-changes.md.txt#deprecations)), 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.

> [!NOTE]
> **Note:** Since some platforms (like Apple or JavaScript) share a single version number across the different product SDKs, a change to one constituent product SDK will cause the version of the others to be bumped as well. For example, a change to the JavaScript SDK for Realtime Database will cause a version bump for all other product SDKs for JavaScript.
>
> However, other platforms (like Android or Flutter) have independent
> versions for their product SDKs, so a change to one product SDK will not
> affect the version of the others.

#### 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).

<br />


*** ** * ** ***

<br />

## **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](https://cloud.google.com/apis/design/versioning)

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](https://cloud.google.com/apis/design/versioning#channel-based_versioning)
was the recommended model when the API was launched, and Firebase used it.

Here are some examples:

- Cloud Firestore uses release-based versioning:

  - [https://firestore.googleapis.com/v1/{name=...}](https://firestore.googleapis.com/$discovery/rest?version=v1)
  - [https://firestore.googleapis.com/v1beta1/{name=...}](https://firestore.googleapis.com/$discovery/rest?version=v1beta1)
  - [https://firestore.googleapis.com/v1beta2/{name=...}](https://firestore.googleapis.com/v1beta2/%7Bname=)
- App Check uses channel-based versioning:

  - [https://firebaseappcheck.googleapis.com/v1/{name}](https://firebaseappcheck.googleapis.com/$discovery/rest?version=v1)
  - [https://firebaseappcheck.googleapis.com/v1beta/{name}](https://firebaseappcheck.googleapis.com/$discovery/rest?version=v1beta)

### 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).

<br />


*** ** * ** ***

<br />

## **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](https://firebase.google.com/policies/changes-to-firebase/introducing-and-communicating-changes.md.txt#end-of-maintenance).