Skip to content

Release 0.4

This page is the development draft for the Incan 0.4 release notes. It records the intended release shape early so release notes, feature inventory updates, and docs changes can land alongside the implementation work rather than being reconstructed at freeze.

0.4 is a tooling, inspection, installer, starter, and first-contact release. The working thesis is:

0.3 made real programs credible. 0.4 makes the stack tryable.

0.4 should make it practical for someone outside the repository to install Incan, create a small project, run it, test it, understand failures, inspect generated artifacts, and hand compiler facts to humans, editors, CI, and agents. It should not reopen broad language/runtime scope unless the change directly supports that tooling path.

Planned release surface

  • Install and first run: a canonical SDK installer, release manifest, checksum verification, and a zero-clone starter flow.
  • Diagnostics: stable JSON diagnostics and an incan explain catalog backed by shared diagnostic data rather than terminal prose.
  • Build and generated output inspection: build reports and intentional generated Rust inspection commands that explain current backend output without promising a stable Rust ABI.
  • Semantic inspection: a compiler-backed codegraph export for files, modules, declarations, imports, exports, diagnostics, spans, and degraded-state facts.
  • Performance and observability: visible phase timings and cache/preheat evidence for long-running test and build phases.
  • Boundary parity: compact regression fixtures that cover import, reexport, package, test-batch, dependency vocab, and generated-Rust boundaries before downstream packages rediscover the same class of issue.
  • First-contact docs: quickstart and positioning pages that explain what Incan is good for, what it is not trying to replace, and how it fits alongside Python and Rust.

Scope guard

The 0.4 release is not the home for std.web, std.http, Hees.ai product implementation, broad InQL/Pallay SDK work, source-local feature metadata, Rust caller/ABI architecture, or backend replacement. Those directions remain important, but they belong to later release lanes unless a small piece directly supports the install, starter, diagnostics, inspection, build-report, or codegraph path.

Development progress

  • Boundary parity fixtures: 0.4 now starts with a compact regression lane for package-boundary helper calls that move through provider, facade, and consumer modules. The fixture exercises dependency-owned union values, public helper aliases, method calls, list arguments, and generated Rust ownership so future import/reexport regressions fail inside Incan before downstream packages rediscover them.
  • Checked API identity reuse: public import resolution and backend method lookup now reuse checked API metadata when manifest aliases point through facades. That keeps public helper/type identity attached to the provider declaration instead of reconstructing a second answer from stale manifest-only surfaces.
  • Partial preset const metadata: model-constructor partials can now materialize const metadata values when their preset and call-site arguments are named and const-valid. This includes the FrozenStr/str compatibility needed by metadata builder presets without turning partial calls into a separate const-evaluator path.

Tracking issues

  • #223: 0.4 umbrella.
  • #554: release direction notes.
  • #592: RFC inspectability prompts.
  • #760: compact boundary parity fixture suite.
  • #699: unified symbol identity across import and package boundaries.
  • #753: partial presets constructing const metadata values.
  • #707 and #723: preheat/progress observability.
  • #697: generated-library dependency preheat when timing evidence requires it.
  • #589 and #590: stable diagnostics and explain catalog.
  • #591 and #567: build reports and generated Rust inspection.
  • #666 and #573: semantic inspection and codegraph export.
  • #428, #553, and #551: installer, starter flow, and first-contact docs.