Skip to main content
Version: 0.18.21

Feature and code readiness

The following are the readiness levels for Great Expectations features and code:

  •   Experimental: Try, but do not rely
  •   Beta: Ready for early adopters
  •   Production: Ready for general use

These readiness levels allow experimentation, without the need for unnecessary changes as features and APIs evolve. These readiness levels also help streamline development by providing contributors with a clear, incremental path for creating and improving the Great Expectations code base.

The following table details Great Expectations readiness levels. Great Expectations uses a cautious approach when determining if a feature or code change should be moved to the next readiness level. If you need a specific feature or code change advanced, open a GitHub issue.

Criteria Experimental
Try, but do not rely
Beta
Ready for early adopters
Production
Ready for general use
API stabilityUnstable ¹Mostly StableStable
Implementation completenessMinimalPartialComplete
Unit test coverageMinimalPartialComplete
Integration/Infrastructure test coverageMinimalPartialComplete
Documentation completenessMinimalPartialComplete
Bug riskHighModerateLow

¹ When an experimental class is initialized, the following warning message appears in the log:

Warning: great_expectations.some_module.SomeClass is experimental. Methods, APIs, and core behavior may change in the future.

Expectation contributions

Create and manage Custom Expectations explains how you can create an Expectation with an experimental status. The print_diagnostic_checklist() method provides you with a list of requirements that you must meet to move your Expectation from experimental to beta, and then to production. The first five requirements are required for experimental status, the following three are required for beta status, and the final two are required for production status.

Criteria Experimental
Try, but do not rely
Beta
Ready for early adopters
Production
Ready for general use
Has a valid library_metadata object
Has a docstring, including a one-line short description that begins with "Expect" and ends with a period
Has at least one positive and negative example case, and all test cases pass
Has core logic and passes tests on at least one Execution Engine
Passes all linting checks
Has basic input validation and type checking
Has both Statement Renderers: prescriptive and diagnostic
Has core logic that passes tests for all applicable Execution Engines and SQL dialects
Has a robust suite of tests, as determined by a code owner
Has passed a manual review by a code owner for code standards and style guides