Repository navigation
Roadmap: M0 to M8 #2
Description
Activity
Triage
Category: Feature Request (tracking issue)
Priority: Medium
Area: repository roadmap, M0–M8Medium as a tracking issue — it carries no work of its own; the priority that matters is on the milestone issues beneath it. Flagged here mainly because it is the one place the cross-repo dependency web is written down, and two entries in that table have moved since it was filed.
Suggested assignment: none specific.
Related — two upstream dependencies now have open PRs, so the table is out of date:
- Semantics#239 (
StorageMath.Sqrt<T>internal, blocks M1) — open PR Make StorageMath public, and add Cbrt, RootN and Hypot Semantics#247, "Make StorageMath public, and add Cbrt, RootN and Hypot". If it merges, the M1 row's "has to be reimplemented here" stops being true. - PreciseNumber#78 (blocks M3) — its roots sub-issue is open PR Implement IRootFunctions<PreciseNumber> with Sqrt, Cbrt, RootN and Hypot PreciseNumber#86. Concurrent lookups for the same CelesTrak or IERS key each hit the network, so the "enforced, not advisory" refetch limit fails as soon as two callers overlap #78 itself remains open with three sub-issues; Keep one bad snapshot file from costing an object its history #81 and Add the element inspector panel #82 are unstarted.
The other rows are current: Semantics#237, #240 and ImGuiApp#411, #413 are all open with no PRs. Semantics#244 (recorded as worked around with
PrivateAssets="all") is triaged High in its own repo with no fix in flight, so the workaround stays for now.Open PR covering this: none.
Suggested next step: the M2 sequencing problem is raised in both this issue and #3, and answered in neither — it is the one open decision on the critical path, so it is worth resolving in one place and having the other defer to it rather than restating the options twice. On the roadmap itself, the choice not to file M3–M8 as placeholders is a good one and worth keeping; the table does that job without generating tracker noise. Refreshing the two dependency rows above would keep it doing its job accurately.
Generated by Claude Code
- Semantics#239 (
Tracking issue for the milestones in
docs/spec.md.M5 is the milestone that justifies the project. Everything before it is infrastructure; everything after it is elaboration. Every quantitative figure in the spec is a projection until M5 replaces it with a measurement.
Sgp4<T>generic,doublepathPreciseMath, thePreciseNumberpath, high-precision πM3 onwards are deliberately not filed yet. Their content is in the spec, and filing thin placeholders for work months out is tracker noise — each gets an issue when it is next.
Upstream dependencies
PreciseNumberimplementsINumber<T>and nothing else — noSqrt,Sin,Cos,Atan2, all of which SGP4 needs.Osculator.Math.Precisesupplies them locally until it lands.From{Unit}factories, so everyPosition3Dis built in raw metres with a hand-written ×1000.StorageMath.Sqrt<T>isinternal, so the type-generic Newton root has to be reimplemented here.GravitationalParameterdimension, so μ is carried as a bareT.PrivateAssets="all"; recorded so the workaround can be removed when it is fixed.None of these block M1, whose gate is the
doublepath.A sequencing problem in the spec, worth settling before M2
M2's loop is "propagate an old element set forward and compare against a later one for the same object" — which needs an element-set history. CelesTrak serves the current elements for an object, not past ones. So M2 as specified either:
Option 2 pulls a credentialed data source forward into the milestone the spec wanted to depend on only CelesTrak. Option 1 keeps M2 auth-free but makes its gate untestable on day one. Raised in #3.