Roadmap
This page does not track status
Every work item lives on GitHub. This page explains why the work is ordered the way it is — the part that does not change when a checkbox gets ticked.
- What is planned, in progress, or done → project board
- What a version must satisfy → milestones
- What exists today → capabilities
- How to propose something → where things go
If this page and GitHub disagree, GitHub wins. Deliberately, there is not a single item checklist below — a checklist here would go stale the first time someone closed an issue.
Axiolid is an early geometry kernel striving to become a multipurpose, exact B-rep kernel — for CAD construction, for rule checking over building models, and for the analysis those applications need. This page orders that work; it is not a promise of dates, and listing something here is not a claim that it exists.
The ordering principle
Build the meat of the kernel first, shape it for performance later.
Correctness and exact geometry come before speed. We keep following good practice — layering, feature isolation, provider seams, measured oracles — so that optimization stays possible when its turn comes. We do not trade capability for benchmarks now.
This is why performance work is parked rather than declined: the ordering is intentional, and each parked item carries a written unblock condition. See ADR 0013.
Why the milestones are shaped this way
Milestones are capability gates, not dates. Each one exists because the next cannot be honestly attempted without it.
| Milestone | Why it comes when it does |
|---|---|
| v0.2 — Exact B-rep survives operations | The kernel evaluates exactly but caches every graph node as triangles, so exactness dies at the first edge (ADR 0020). Nothing exact is trustworthy until a cylinder survives an operation as a cylinder. |
| v0.3 — Intersection and inversion | Exact booleans, section curves, offsets, and fillets all reduce to intersection and inversion. Attempting them before the exact representation holds would build on sand. |
| v0.4 — Trustworthy discrete geometry | The mesh path stays supported for callers who explicitly want discrete results — and it is the differential oracle for the exact path, so it must be trustworthy after there is an exact path to check against. |
| v0.5 — Compiled geometry and plans | Reproducible operation plans need stable exact semantics underneath. Freezing a plan format over shifting geometry would bake in the wrong contract. |
| v1.0 — Stable public API | An API is only worth stabilising once the capability surface behind it is real. Committing earlier would freeze scaffolding. |
Minor versions can be inserted between any two of these at any time. The sequence is an ordering constraint, not a fixed count.
What this kernel refuses to do
These are not backlog items. They are boundaries, and they do not expire.
- Not a file parser. IFC, STEP, and CAD source semantics belong in adapter projects. Representing imported data is not the same as parsing a format.
- No C++ in the dependency graph. Including OpenCascade. Pure Rust is a hard constraint, not a preference.
- A type is not an implementation. A feature flag, provider seam, or vocabulary type is never evidence that an algorithm is production-ready. Capability claims need an executable implementation and a test.
- No performance claim without same-harness evidence. Benchmarks currently exist for
axiolid-referenceandaxiolid-mesh-boolean-boolmeshonly. There are no broad performance claims to defend, and none should be made.
Release discipline
Semantic versioning: patch for compatible fixes, minor for compatible capability additions during 0.x, and a documented breaking-change policy before 1.0. The changelog records user-visible changes.
Releases are deliberate, reviewed changes rather than automatic tags. Automating that is itself tracked work, not a claim about today.