This topic explains LaunchDarkly’s SDK versioning policy, which is based on the semantic versioning standard.
To set up notifications about version updates and end of life notices, read Version notifications.
In summary, the semantic versioning standard specifies that each version should be uniquely labeled by an identifier made up of three components:
These components are separated by periods. For example: The version 1.2.3 has a major version of 1, a minor version of 2, and a patch version of 3.
For pre-release versions, we may suffix the version with an identifier indicating the version’s pre-release status, like -beta1 or -alpha2.
When we release a new version, we increment one of the major, minor, or patch components. Differentiating between new versions is based on the kinds of changes introduced in the new version.
As is conventional in the semantic versioning standard:
To learn more, read Semantic Versioning 2.0.0.
The semantic versioning standard is a set of guidelines, not rigid rules. Different products and companies interpret the standard in ways that make sense to them.
At LaunchDarkly, we version our SDKs based on the following criteria:
We release a patch version to modify a behavior if correcting that behavior does not change any documented types, properties, methods, or parameters.
We release a patch version to modify a behavior when:
“Documented” behavior is behavior that is referenced or explained in technical documentation we provide about LaunchDarkly, or behavior that exists in the public API.
“New functionality” is not a term that applies to all new behavior.
It means providing you the ability to do something with the SDK that you could not do before and that involves a new type, property, method, optional parameter, or supported parameter value.
New functionality qualifies as a minor version release.
A “breaking change” occurs when a type, property, method, parameter, or allowable parameter value is no longer defined or no longer produces the results or behavior you want when you use it according to the documentation we provide.
The qualifications for a breaking change can vary from platform to platform. On a platform like Node.js, which does not have the same kind of public and private visibility systems as Java or .NET, it can be difficult to distinguish between internal code and APIs.
In cases like this, internal methods or properties can exist that LaunchDarkly cannot prevent application code from accessing, including methods and properties which are excluded from all documentation and from explicit interface declarations. We consider methods and properties like that, such as TypeScript declarations, to be internal. We do not consider breaking these internal references to be breaking changes as long as the underlying behavior persists. We will not release a major version solely to resolve an internal breakage.
Examples of breaking changes that would qualify for a major version release include:
For information on breaking changes and how to upgrade safely between major versions, look for the relevant migration guide for your SDK: Find the reference guide for your SDK from the complete list of SDKs, then use the left navigation in that documentation topic to find the migration guide for your version.
For details on non-breaking changes in minor or patch versions of an SDK, review the details in the GitHub release: Find the reference guide for your SDK from the complete list of SDKs, then click the “GitHub repository” link in the “SDK quick links” callout.
SDK versions reach their end of life (EOL) one year after we release the subsequent version. For example, if we release SDK version 3.9.x on January 1, 2026, then the previous 3.8.x version will reach its EOL on January 1, 2027.
After an SDK version has reached its EOL, its behavior may be unpredictable. This can mean:
You can view the currently supported versions of all LaunchDarkly SDKs at Supported versions.