Current release and support¶
This is the public release-status source of truth. Other pages link here instead of maintaining their own release story.
1.3 is published
Hedron 1.3.0 is available from PyPI. The documentation describes the stable Hedron 1.3 API contract.
At a glance¶
| Package | Version | Maturity | Application requirement | Role |
|---|---|---|---|---|
hedron |
1.3.0 |
Stable | hedron>=1.3.0,<1.4 |
FastAPI-native component and route authoring |
hedron-data |
1.3.0 |
Stable | hedron-data>=1.0.0 |
DataTable, DataEditor, and bounded data contracts |
hedron-charts |
1.3.0 |
Stable | hedron-charts>=1.0.0 |
First-party charts and static/Matplotlib output |
hedron-maps |
1.3.0 |
Stable | hedron-maps>=1.0.0 |
Bounded first-party maps and offline presentation |
edron |
1.3.0 |
Stable | edron>=1.3.0,<2.0 |
Alternate class-oriented facade over Hedron |
The coordinated release supports CPython 3.11–3.14. Package maturity, capability readiness, and individual API stability are separate: a stable package may contain a clearly labeled experimental capability.
Python 3.10 has reached end of security support and will receive no further CPython security fixes. The published 1.3.0 release requires CPython 3.11 or newer. Recreate the environment under Python 3.11–3.14 before upgrading.
The exact Stable package and API boundary is maintained in the repository’s
release/support-matrix.toml;
the 1.3.0 release is published, and the same versioned source is available from PyPI. Beta
host/tooling satellites are opt-in compatibility
surfaces, not part of the stable platform contract.
What should I install?¶
| Goal | Continue with |
|---|---|
| New FastAPI/component application | Hedron quick start |
| Dashboard, CRUD app, or data workflow | Hedron guides |
| Existing Flask or Django application | Installation and host adapters |
| Repository contribution | uv sync, then Contributor day one |
The table's >=1.0.0 values are compatibility floors, not the recommended production lock.
For a new Hedron application use hedron>=1.3.0,<1.4; for reproducible CI and deployment,
resolve and commit a lockfile or use hedron==1.3.0. Reusable libraries may use the broader
>=1.0.0 floor when they test against the full supported range. Upgrade deliberately after
reading the release notes and running the application's own integration tests.
Support lifecycle¶
| Train | Security support | Compatibility expectation |
|---|---|---|
1.3.x |
Current published train | Stable APIs follow the 1.x compatibility policy |
1.0.x |
Best-effort security triage through approximately 2027-02-27 | Upgrade to 1.3; migration aliases are not the new golden path |
Earlier 0.x |
Unsupported | Use historical documentation only to plan an upgrade |
There is no commercial SLA. Community support is provided through GitHub; security reports follow SECURITY.md, not public issues.
Stability and deprecation¶
- Stable: compatibility-protected for the documented 1.x contract.
- Beta: usable with pins, but its contract may change in a future minor release.
- Experimental: opt-in evaluation surface with a documented production fallback.
- Deprecated: retained temporarily for migration and absent from new quick starts.
Removal of a stable API requires a deprecation notice, migration guidance, and a future major release. See Stability and Upgrade.
Coordinated and independent packages¶
hedron-core, hedron, Edron, hedron-data, hedron-charts, and hedron-maps use the
coordinated 1.2 Stable contract in the repository. Host adapters and vendor/tooling satellites
retain independent versions and Beta maturity.
Do not infer satellite compatibility from a similar
version number; use the compatibility matrix.
The Workbench split is intentional:
| Package | Role |
|---|---|
hedron-posit |
Coordinated Hedron facade for Posit Workbench and Connect |
fastapi-workbench |
Independent generic adapter for plain FastAPI/ASGI applications |
hedron-workbench |
Removed compatibility distribution |
Release maintenance¶
The values rendered in release callouts and install matrices come from
docs/release.toml. A release change begins there and must pass the
documentation source-of-truth, API coverage, link, and strict build checks. Historical release
pages remain historical; they are not edited to masquerade as the current release.