The original numbered milestone plan is now historical context rather than the authoritative day-to-day
tracker. Current planning is workstream-based and closes against explicit parity, readiness, and probe gates.
Current Workstreams
Workstream
Current focus
Release readiness
Installation polish, public docs accuracy, supported-platform packaging, and remaining pre-release hardening.
Runtime + stdlib long tail
CPython 3.14 parity closure across remaining stdlib/runtime edge behavior and mapped test gaps.
Native extensions + scientific stack
C-API lifetime-model closure, NumPy bring-up blockers, and broader extension compatibility for real workloads.
Performance + architecture
Observability, benchmark discipline, and deeper VM/runtime cleanup without regressing semantics.
How Closure Is Tracked
Workstream
Current focus
Release blockers
docs/PRODUCTION_READINESS.md and docs/STUB_ACCOUNTING.md.
Stdlib/runtime baselines
docs/STDLIB_FULL_BASELINE.md and perf/stdlib_full_probe_latest.json.
Language parity
docs/LANGUAGE_FEATURE_MANIFEST.json and the latest language coverage artifacts.
Native extensions/scientific stack
docs/CAPI_PLAN.md, docs/CAPI_LIFETIME_MODEL.md, and docs/NUMPY_BRINGUP_GATE.md.
Legacy Milestone Note
Area
Rule
Historical numbering
The old 0-16 milestone map is still useful as rough historical scope, but it is no longer the primary status source.
Current practice
Use the linked readiness/probe docs for current status instead of assuming milestone labels are current.
Why keep this page
It gives high-level direction and points at the trackers that actually determine launch readiness.
