Documentation Status and Conventions¶
Prefer pages marked Available in 0.21 and the Green path on the docs home. For what ships in the current package, start with Capabilities—not chapter length or this legend.
How to read a page¶
- Read the page status label first (table below).
- Treat Available in 0.21 / Shipped in 0.x as current package behavior; treat Future design and Design Proposals as intended 1.0 surfaces, not APIs to install against.
- Treat Experimental as public but changeable without a major bump.
- When a guide and a normative spec disagree, the spec wins (ODCS, DTCS, DPCS). Integration chapters explain ETLantic usage; they do not replace those specs.
- Keep design layers distinct: contracts →
PipelinePlan→ plugin / compiled artifact → run result.
Page status labels¶
| Page status | Meaning |
|---|---|
| Available in 0.21 | Tested against the current package |
| Shipped in 0.x | Available since that milestone (still current) |
| Experimental | Public APIs that may change without a major version bump |
| Partially available | Shipped and future behavior are explicitly separated |
| Future design | Not a current API or installation guide |
| Normative specification | Contract requirements, not package behavior |
| Internal project plan | Maintainer sequencing and implementation notes |
Conceptual stability labels¶
Documents also use these conceptual levels (usually in design or foundation chapters):
| Label | Meaning |
|---|---|
| Foundational | A project boundary or principle expected to remain stable |
| Accepted design | A chosen API or architecture direction pending implementation |
| Proposed | A concrete surface that may change as implementation pressure appears |
| Normative | A requirement defined by a contract specification |
| Example | Illustrative code that expresses intended UX |
See also¶
- Capabilities — current shipped surface
- Roadmap
- Design Decisions
- Architecture Decisions