Rasa Product Release and Maintenance Policy

Summary

In order to enable our customers to innovate and to support our continued development and innovation, we have chosen to implement the following Product Release and Software Maintenance Policy. Our End of Life policy defines how long a given release is considered supported, as well as how long a release is considered to be still in active development or maintenance. We provide more information about this in our support policy which includes our support SLAs.

Versioning

Rasa has implemented robust policies governing version naming, as well as release pace for major, minor, and patch releases. Rasa Enterprise, Rasa Pro, and Rasa Open Source adhere to Semantic Versioning, as follows:

The values for a given version number (MAJOR.MINOR.PATCH) are incremented as follows:

• MAJOR version for incompatible API changes or other breaking changes.
• MINOR version for functionality added in a backward compatible manner.
• PATCH version for backward compatible bug fixes.

For example, the Rasa Open Source 3.2.4 release can be read as follows:

• 3 represents the major version. The major release was 3.0.0 but often referred to as 3.0
• 2 represents the minor version. The minor release was 3.2.0 but often referred to as 3.2
• 4 represents the patch number

Release Frequency

The following table describes the version types and their expected release cadence:

While this table represents our target release frequency, we reserve the right to modify it based on changing market conditions and technical requirements.

End of Life Process

The End of Life (EoL) process is intended to guide the final business operations associated with a Rasa product, service, or subscription life cycle. The end-of-life process consists of a series of technical and business milestones and activities that, once completed, make a product, service, or subscription obsolete. Once obsolete, the product, service, or subscription is not sold, improved, maintained, or supported.

We have set out below Rasa’s End of Product Lifecycle milestones to help manage the EOL transitions and to explain to customers how, and when to migrate to alternative Rasa products and services. The Rasa platform is an intricate system of multiple products. It also depends on a large set of third-party libraries that are independently maintained and deployed through dependency installation scripts. The End of Life process and policy we established are aligned with the major components’ support policies. It is for this reason that we actively encourage our customers to stay up to date on the Rasa software versions they use in production and have an active migration program that is aligned with this End of Life Process and Maintenance timelines. 

Types of Releases

Major versions, such as 2.0.0 and 3.0.0 provide us with an opportunity to introduce features and break backward compatibility. Minor versions, such as 2.8.0 and 3.2.0, provide us with an opportunity to introduce features. Patch releases, such as 2.8.14 and 3.1.2, fix bugs only. Maintenance activity occurs on all releases that have not reached the end of life, but we focus on the minor release stream (e.g., 3.2.x) to define how long we maintain a particular code line. Active maintenance of a minor release implies that we are fixing bugs and backporting some number of fixes into that code branch.

Maintenance Policy

Commercial Support

The following policy applies to all customers with commercial licenses of Rasa products, including Rasa Open Source, Rasa X/Enterprise, Rasa Pro, and associated packages and APIs.

Customers who have purchased a Rasa subscription (regardless of support tier) should expect functional and security bug fixes in the form of a patch release for nine (9) months from the release date of the initial minor version of a given major version. Once Rasa releases the next major release, effectively putting an end to any minor feature releases on the previous major, the last minor release will have an extended support date of twelve (12) months from the initial release date of the last minor. This becomes the Extended Support (ES) release. Technical support is provided for an additional six (6) months from the End of Software maintenance date of every minor release.

More detailed information with actual dates will be maintained in the maintenance table below.

Community Support

Our goal for community users of Rasa Open Source is to maintain the most recent minor release from the current major release stream. This allows these users to obtain packaged fixes on the latest branch while making only minor changes to their running software.

From time to time we may backport fixes to other minor release streams. For example, a serious security patch might be ported to multiple branches and a release may be packaged to include this patch. We will use our discretion when deciding to do this, but expect it to be very infrequent.

Definitions

“End of Software Maintenance” is the date after which the product is no longer maintained by development engineering. This is also the last date engineering may issue functional or security patches to the product. All upgrades to actively supported versions should be completed by this date.

“End of Technical Support” is the last date to receive applicable service and support as entitled by active service contracts for covered products. This additional support window is a grace period for completing upgrades that weren’t finalized before the end of software maintenance date. After this date, support services are no longer available.

“Extended Support” is how Rasa identifies a release that will receive an extended period of support for subscription customers. This will typically be associated with the last minor release of a given major release.

Upgrade Policy

Upgrading from a prior Major Version

When upgrading from a previous major, for example, 2.8, the latest minor of a major should be picked as the version to upgrade to, for example, 3.2. All software and security patches will have been applied to that minor.  Please note that upgrades of one product may require an upgrade to another dependent on it. Please refer to the Compatibility Matrix for more details.

Upgrading multiple Major Versions

Upgrading from older versions, for example, 1.10, to a newer major version, for example, 3.2, always requires an upgrade to any intermediate major version first. For the mentioned example, an upgrade from 1.10 to 2.9 should be performed, and then followed by an upgrade from 2.9 to 3.2. No major version should be skipped.

Maintenance Tables

The following tables are simplified descriptions of the above policy. There may be occasions where we release a new minor version after a new major version is released. In that case, the tables below will be updated and the above-written policy will take precedence.

Rasa Pro

The table below applies to Rasa Pro (and previous Rasa Plus releases). Go to the next table for Rasa Pro Services.

Rasa X/Enterprise

For compatibility of Rasa X/Enterprise with Rasa Pro or Rasa Open Source, please refer to the Compatibility Matrix in the references section below.

References

Rasa X/Enterprise Compatibility Matrix

https://rasa.com/docs/rasa-enterprise/changelog/compatibility-matrix

Rasa Pro Compatibility Matrix

https://rasa.com/docs/rasa-pro/compatibility-matrix

Rasa X/Enterprise Change Log

https://rasa.com/docs/rasa-enterprise/changelog/rasa-enterprise-changelog

Rasa Pro Change Log

https://rasa.com/docs/rasa-pro/rasa-pro-changelog

Rasa Open Source Change Log

https://rasa.com/docs/rasa/changelog

Rasa Action Server SDK Change Log

https://rasa.com/docs/action-server/rasa-sdk-changelog

Version Migration Guide

https://rasa.com/docs/rasa-pro/migration-guide