Versioning and Support Policy

In this section we detail the versioning schema for Fusebit platform components and the support policy we follow.

Component Versioning

The Fusebit platform is comprised of the following components:

  • Fusebit CLI
  • Fusebit editor
  • Fusebit HTTP API
  • Fusebit operations CLI (only available for Private Deployment customers)

Each of these components is versioned according to the Semantic Versioning 2.0 specification, using a {major}.{minor}.{patch} tuple. Each component versions independently, so a certain component might be at version v1.3.0, while another at version v3.4.12.

All reference documentation is versioned according to the versioning scheme of the respective component.

Platform versioning

The Fusebit platform is an umbrella term that encompasses all of the above components. The platform itself is also versioned, but uses just just a {major}.{minor} version, such as v1.3.

The platform major version will be incremented in the following cases:

  • Any component of ships a breaking change (increments its major version)
  • There is major new functionality added to the stack that we want our customers to know about
  • A new LTS release is released (see below)

The platform minor version will be incremented when:

  • Any component ships an incremental non-breaking change

An example platform release might look like this:

Fusebit platform v1.3

  • Fusebit CLI v3.3
  • Fusebit editor v1.4
  • Fusebit HTTP API v2.5

Within a platform version, all patch versions of a given component are supported and guaranteed to work together, as long as they have the same major and minor version that is indicated in the platform release.

All non-reference documentation is versioned according to the platform version it applies to.

Long Term Support

This section describes our support policy around current and past platform versions.

Cloud Deployment Customers

Customers running inside Fusebit's cloud deployment are almost always running on our most current Fusebit platform version. This represents the "head" of our development tree and contains the latest features, upgrades, enhancements, and bug fixes. The only way we ever service the current platform release is by shipping a newer release, which is applied automatically and transparently in our cloud environment.

Private Deployment Customers

For certain customers, where data locality and compliance are a concern, Fusebit offers a private deployment model where the platform runs on the customer's cloud infrastructure instead of Fusebit's public cloud. Under this model a customer can operate the stack with minimal or no access by the Fusebit team. We make two types of releases available to private deployment customers:

  • Curent Fusebit platform release: represents the "head" of our development tree and what is deployed to our cloud deployment customers. It contains the latest features, upgrades, enhancements, and bug fixes. The only way we ever service the current platform release is by shipping a newer release. So if a private deployment customer chooses to take a dependency on the current Fusebit platform and later finds they need a bug fix, their only option is to upgrade to the a subsequent Fusebit platform release that contains the fix as well as any other features, enhancements, changes, including breaking changes, that may have occurred.
  • Fusebit platform Long Term Support (LTS) release: represents a selected Fusebit platform version that we commit to supporting for 15 months. We cut a new LTS release every 12 months in September. This means a customer who always wants to stay on LTS releases must upgrade on average every 12 months and has a 3-month window to do so. Any critical issues (security, legal, etc) discovered after the original release date will be back-ported to the LTS release.