On This Page

Home /Versioning

Versioning

Preview Feature
​

The Cribl SDKs and Terraform provider are Preview features that are still being developed. We do not recommend using them in a production environment, because the features might not be fully tested or optimized for performance, and related documentation could be incomplete.

Please continue to submit feedback through normal Cribl support channels, but assistance might be limited while the features remain in Preview.

The versioning policy for the Cribl API, SDKs, and Terraform provider is based on the semantic versioning standard. For example, if the version number for a release is 4.14.1, the 4 represents the major version, 14 the minor version, and 1 the patch version.

Cribl increments one of the three elements of the version number for each new release, depending on whether the release is a major, minor, or patch release.

API Versions
​

Cribl API version numbers align with Cribl releases. The API version automatically increments with each Cribl release.

The Cribl as Code documentation reflects the latest version of the API. Refer to the API Reference for documentation for earlier versions.

SDK Versions
​

The initial Cribl SDKs are released for public preview at version 0.1.0.

SDK version changes are based primarily on changes in the OpenAPI document that defines the Cribl API. SDK versions are automatically incremented with each Cribl release, although SDK version numbers do not necessarily correspond with API version numbers or Cribl release numbers.

The Cribl as Code documentation reflects the latest versions of the SDKs. Refer to the GitHub repository for each SDK for earlier versions:

Terraform Provider Versions
​

The Cribl Terraform provider versions automatically increment when the code is updated.

The Cribl as Code documentation reflects the latest version of the Cribl Terraform Provider. Refer to the Terraform Registry or the terraform-provider-criblio GitHub repository for earlier versions.

Breaking and Non-Breaking Changes
​

Only major releases include backward-incompatible (breaking) changes. Examples of breaking changes include removing endpoints, modifying response schemas, and retiring an API version.

Minor and patch releases include only non-breaking changes. Minor releases may include backward-compatible features and enhancements, such as new endpoints and extended response payloads with new parameters. Patch releases are limited to backward-compatible bug fixes such as typos in error message descriptions, misordered fields in SDK metadata, and missing fields in request or response objects.