Deprecation Policy

Overview

FusionAuth is an architectural component integrated into your applications or systems. Such integration means that when changes to FusionAuth occur, it can negatively affect your application. As developers ourselves, we strive to maintain backwards compatibility.

However, there are times when features or functionality must be removed. FusionAuth has extensive release notes, which are the source of truth for changes to the FusionAuth system, and any deprecated features will be listed there. Changes to existing features or behavior will also be documented in the release notes.

Because we feel backwards compatibility is important, the FusionAuth team will follow the process outlined in this document before removing features or making breaking changes to existing features.

What Is A Feature

Here are examples of features that will follow this policy.

• A documented API endpoint or parameter
• A documented way to authenticate against an API
• A documented themeable page

What Is Not A Feature

Anything not documented in the FusionAuth technical documentation is not considered a feature and may be removed without following this policy.

What Is A Release

The releases mentioned in this document are either major or point version releases. Patch releases do not change functionality.

• 2.0.0 is a major release.
• 1.50.0 is a point release, as is 1.51.0.
• 1.50.1 is a patch release, as is 1.50.2.

Deprecation Steps

Before removing a feature, the FusionAuth team takes the following steps:

• In the first major or point release where the behavior is deprecated, the deprecation is noted in the release notes. The feature is also marked as deprecated in the documentation.
• The feature deprecation is noted in the documentation for three months.
• In a major or point release after the three month deprecation period, the feature and corresponding documentation are removed. When the feature is removed, it is noted in the release notes. The documentation for the feature is also removed.

While the team commits to maintaining features for at least three months after they are deprecated, that timeframe is a minimum.

Example Removal Timeline

Suppose the current release is 1.52.0 and FusionAuth planned to remove feature ABC in the next release. Here is what the timeline would look like.

Policy Exceptions

If this is a change adding new functionality which may require changes to your integration, the FusionAuth team won’t follow this policy. This only applies to deprecation and removal of functionality. We will still do our best to document such changes in the release notes to help developers understand what needs to change, or if nothing needs to change based upon your implementation. But such changes fall outside of this deprecation policy.

If a feature impacts performance or security, FusionAuth reserves the right to deprecate features in a different manner than outlined in this policy.

Examples of performance issues include:

• A performance degradation due to a new feature which was not caught in testing.
• A feature which introduced deadlocks in the database due to a corner case.

Examples of security issues include:

• A feature that pentesting determined was vulnerable to attack.
• A SAML feature exposing an XML parsing issue.

Regardless of when a feature was added, if the team finds a large risk to our customers, we may delete it without warning. In this case, the team will notify the security announcement email list.