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 local `gf` workspace jobs explain where elapsed time goes. A developer should be able to distinguish queue delay, workspace/write contention, compute, filesystem I/O and sync, provider/network waits, verification, publication, retries, cleanup, and failure without exposing workspace contents or requiring a hosted service. ## In scope - Rust-owned, disabled-by-default OpenTelemetry runtime for local development; - one root trace per local workspace job with enqueue/start/finish and finite stage/wait/outcome semantics; - deterministic queue, active, stage, explicit-wait, attempts, exact bytes/records, and residual-time accounting; - bounded local session aggregates for recurring bottlenecks, queue depth, concurrency, and failures; - thin CLI/Python/Node context/configuration projections; - local structured output and/or local collector workflow, executable examples, privacy fixtures, and a slowdown runbook; - Hub clone as a concrete local job profile. ## Out of scope - managed-cloud usage accounting, billing, quotas, tenants, project/user dashboards, hosted telemetry, production APM, automatic remote export, raw query/command capture, workspace paths/identifiers, graph data, property data, credentials, or binding-owned semantics. ## Close criteria Close when local fixtures prove that queued, contended, compute-heavy, I/O/sync-heavy, network-heavy, retrying, and failed jobs identify the correct bounded stage or wait; timing math is documented and reconciled; disabled/exporter-failure modes cannot affect jobs; no prohibited data is exported; and a developer can diagnose a deliberately slowed job using only documented local tooling. ## Observable job shape Each local job shows which stable GraphForge API operations ran, their order and wall duration, authoritative CPU time where supported, waits and retries, extensions actually invoked, and import/export phases and exact volume when known. The milestone does not require an internal component inventory. The workspace also provides a fast on-demand Rust statistics operation for exact top-level counts and GraphForge-owned disk footprint. It reads bounded maintained metadata rather than scanning graph data or recursively walking files; thin CLI/bindings expose the same result, and periodic telemetry samples it over time.
No due date•2/5 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