Development documentation
This section explains how pyvoro2 is structured, how planned work is approved and tracked, which parts of the public API are intended to remain stable, and why major design decisions were made. It is written for maintainers, contributors, reviewers, coding agents, and downstream package authors.
Where to look
| Question | Authoritative source |
|---|---|
| How do I use the current package? | User guide and API reference |
| What mathematics does it implement? | Theory |
| How does work move from proposal to release? | Development workflow |
| What work is planned next? | Development plans; no post-v0.8 plan is currently active, and the completed v0.8 cleanup plan and audit remediation plan are archived |
| Which concrete APIs are stable, provisional, experimental, removed, or internal? | v0.8 API inventory and API lifecycle |
| How should repository documentation be written? | Documentation conventions |
| How are modules and layers organized? | Architecture |
| Why was a durable choice made? | Decision records |
| What is planned over several releases? | Roadmap |
| What historical work produced v0.8? | v0.8 audit/remediation record, completed remediation plan, GitHub issues, and milestones |
| How do I prepare a change? | CONTRIBUTING.md |
| What changed historically? | Changelog |
| What is included in v0.8.0? | v0.8.0 release notes |
Authority and status
The current source code and tests remain the source of truth for implemented behavior. User guides and reference pages describe that behavior for callers.
Accepted decision records and architecture documentation define durable
boundaries. An active development plan defines approved release scope and
gates. The v0.7 and v0.8 plans are Completed and archived; no post-v0.8
plan is currently active. v0.8 R1–R9 and the post-R9 COPYING distribution
correction are complete. After source finalization and independent review,
issue #33 qualifies the exact frozen source commit and its artifacts before the
public tag is created. The roadmap describes version-level direction rather
than current functionality.
Detailed progress belongs in GitHub issues. The API inventory is updated with
public changes, and completed user-visible behavior is recorded in the dated
changelog section while a fresh [Unreleased] section remains for future work.
User-facing lifecycle and migration decisions are summarized in Choosing an API and Migrating from v0.6.3 through v0.8.