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 stability | Unstable ¹ | Mostly Stable | Stable |
| Implementation completeness | Minimal | Partial | Complete |
| Unit test coverage | Minimal | Partial | Complete |
| Integration/Infrastructure test coverage | Minimal | Partial | Complete |
| Documentation completeness | Minimal | Partial | Complete |
| Bug risk | High | Moderate | Low |
¹ 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
Creating 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 | ✔ | ✔ | ✔ |
| 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 | ― | ― | ✔ |