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 | ― | ― | ✔ |