Milestones
List view
## Purpose Ship GraphForge v0.6.0 as one coordinated Rust, Python, npm, CLI, agent-skills, documentation, and GitHub Release surface without consuming the final version during release rehearsal or recovery. ## Canonical version contract - The canonical cross-ecosystem prerelease identifier is SemVer `0.6.0-rc.N`, beginning with `0.6.0-rc.1`. - Git tags and GitHub prereleases use the corresponding `v0.6.0-rc.N` form. - Cargo/crates.io, npm packages, CLI, skills, manifests, provenance, checksums, filenames, and release evidence use `0.6.0-rc.N` without the Git-only `v` prefix. - PyPI uses the required PEP 440 normalized projection `0.6.0rcN`; release evidence must prove it maps to the same canonical `0.6.0-rc.N` identity. - Noncanonical cross-ecosystem spellings such as `0.6.0rc1`, `0.6.0-rc1`, or `0.6.0-RC.1` must be rejected outside explicitly defined ecosystem normalization boundaries. - Release automation and CI must parse and validate the structured version; substring replacement or loosely matched version text is not sufficient. ## Release-candidate policy - The first public candidate is `v0.6.0-rc.1`. - Release-process or artifact defects produce `rc.2`, `rc.3`, and so on. They do **not** consume `v0.6.0` or force an artificial `v0.6.1` corrective release. - Every candidate is immutable. Never move a tag, replace published bytes, or reuse an RC version. - All ecosystem versions advance together under the unified-release contract; no registry-specific version drift. - The final `v0.6.0` identity is created only after one candidate passes the complete coordinated publication, clean-install, reopen, registry-observation, checksum, provenance, and documentation gates. ## In scope - v0.6.0 release scope and compatibility freeze - canonical SemVer prerelease validation and ecosystem-specific projections - release-candidate version alignment across Cargo/crates.io, PyPI, npm native/main/CLI/skills, and GitHub - exact-SHA Binding RC, offline rehearsal, publication recovery, and retained evidence - prerelease publication and clean-environment verification - final v0.6.0 promotion, release notes, docs, and post-publication verification ## Out of scope - unrelated post-v0.6 features - silently repairing or overwriting an immutable RC - publishing only one ecosystem ahead of the coordinated surface - treating a registry-normalized spelling as a second release identity ## Close criteria 1. All milestone issues are closed or explicitly moved with documented rationale. 2. CI rejects noncanonical prerelease forms and proves every registry projection resolves to one canonical `0.6.0-rc.N` identity. 3. At least one immutable `v0.6.0-rc.N` candidate has been published and verified across every supported registry and clean consumer surface. 4. The selected candidate has complete exact-SHA evidence, provenance, checksums, recovery disposition, and release notes. 5. Coordinated final `v0.6.0` artifacts are published and publicly observed across crates.io, PyPI, npm packages, GitHub Release, and docs. 6. Final clean-environment install, native load, CLI/skills execution, project reopen, and checksum/provenance verification pass. 7. The milestone is closed only after public release verification—not merely after tagging or the first registry upload.
No due date•0/1 issues closed## Purpose Make GraphForge observable as a privacy-safe embedded graph data engine: applications can export OpenTelemetry traces, metrics, and logs to understand workload volume, cost drivers, reliability, and capacity without turning GraphForge into a hosted service or exposing graph contents. ## In scope - Rust-owned OpenTelemetry configuration, resource identity, exporter lifecycle, and explicit opt-in behavior; - stable, bounded-cardinality semantic conventions for project-level and process-level usage; - execution, mutation, persistence, import/export, and resource-limit telemetry; - cumulative usage accounting analogous to managed database cloud usage: logical records/nodes/edges read and written, stored bytes, transferred bytes, operation counts, duration, and failure outcomes; - normalized top-operation diagnostics with query text and graph data disabled by default; - thin Python, Node, and CLI configuration/projection; documentation, examples, and deterministic test/export evidence. ## Out of scope - a GraphForge-hosted telemetry backend, control plane, billing system, tenant service, dashboard, or distributed execution requirement; - automatic external telemetry export, credentials, network calls, or collection of graph contents, raw query text, UUIDs, property values, local paths, access tokens, or user identifiers; - binding-owned telemetry semantics or foreign runtime fallbacks. ## Close criteria Close when all milestone stories are closed with Rust-owned implementation evidence: opt-in telemetry works through Rust and thin bindings; stable usage, performance, reliability, and capacity signals have documented units and cardinality bounds; sensitive data is excluded by default; exporter failure is isolated from GraphForge behavior; and deterministic tests validate metrics/traces/logs plus documentation and configuration guidance.
No due date•0/4 issues closedProve GraphForge can persist and operate on at least 1,000,000,000 live edges end to end while preserving embedded Rust ownership, and harden three public interchange surfaces: resumable data ingest, portable project packaging/promotion, and streaming result export. In scope: first-fail scale ladder; bounded UUID membership checks; resumable staged Arrow/Parquet ingest; sharded/streamed CSR; portable project v2 with one semantic identity across inspectable expanded and deterministic bundled forms; bounded integrity/compatibility verification; atomic import; ontology/component/settings/artifact and deterministic graph/data-subset export; optional digest-pinned OCI publication/pull with explicit integrity/authenticity separation; streaming query-result export; Python, Node, and CLI parity; final generate/import → publish → reopen/recount → adjacency → 1/2-hop query → bundle → verify → clean import → reopen/query/fingerprint certification. The final scale proof must separately disclose official Graph500 SCALE26/edgefactor-16 input attempts and post-policy live persisted counts. The product gate is >=1,000,000,000 live persisted edges. Target host envelope: <=128 GiB peak RSS, <=1 TiB local NVMe, <=24 hours, with first-fail evidence at lower rungs. Expanded/bundled equivalence, selective packaging, and OCI promotion require deterministic representative-scale conformance; they do not require duplicating the billion-edge payload or uploading it to a hosted registry. Out of scope: distributed execution, server-only architecture, GPU requirements, foreign runtime engines, domain-specific dataset loaders, universal maximum-size claims, a GraphForge registry/server, mandatory cloud publication, graph merge semantics, and committing project data/exports to Git. Close only when the canonical tracker and every milestone issue are closed with deterministic evidence on the final integrated tree.
No due date•18/20 issues closedShip and prove a transport-neutral peer-extension platform over the published gf-api without moving extension behavior into GraphForge Core. In scope: - extension contract, Core delete/boundary CI, and third-party author documentation; - gf-datasets loader/registry infrastructure, reference content, and separate Python/Node packages; - a local-first genealogy reference extension; - an optional queued-authority MCP/HTTP extension as a peer package. Out of scope: - v0.5.0 publication; - MCP, HTTP, authentication, authorization, or server lifecycle in Core; - distributed or multiple storage authorities; - an extension marketplace or UI. Close when milestone tracker #222 and every milestone issue are closed, Core remains buildable with extensions removed, extensions depend only on public APIs, applicable package and clean-install acceptance passes, and the documentation proves the third-party extension path.
Due by September 11, 2026•1/10 issues closed