ROADMAP

Compatibility first. Delivery next. Async last.

The sequence follows technical triggers, not arbitrary dates. Each phase must unlock a real, measurable use case.

NOW

Symfony HttpKernel and the core tail.

With event dispatcher and sessions available, the next stress test is HttpKernel's Request → Response cycle. In parallel: streams, dates, parser edge cases and high-usage builtins.

HttpKernelstream filterstime zonessession tail

NEXT TRIGGER

A full framework route responds.

Once a Laravel or Symfony route runs end to end, preload, server SAPI and standalone packaging begin to provide concrete value.

DISTRIBUTION

Bytecode preload and single binary.

Compile modules once at startup, keep bytecode resident, and embed runtime, prelude and application in a distributable artifact.

RESIDENT SERVER

Reusable, request-isolated VMs.

A VM pool requires reliable state reset, no leaks and benchmarks showing that per-request boot is actually the bottleneck.

LONG-TERM VISION

Native async I/O.

The VM remains synchronous; an external driver suspends and resumes Fibers on thread-per-core runtimes. This only makes sense once real sockets and I/O drivers exist.

ARCHITECTURAL NOTE

Async does not mean turning `Vm::run()` into an async function.

Rc<RefCell<…>> makes VMs and values non-transferable across threads. The documented direction uses a current-thread runtime per core and the existing frame suspension/resumption mechanism.

Advancement criteria

Compatibility before features

A new capability must not break green tests or add APIs that only look correct.

Triggers, not calendars

Preload, pools and async arrive when a real workload demonstrates the problem they solve.

Reproducible measurements

Every milestone needs suites, numbers and a baseline comparable with the oracle.

No opaque shortcuts

Intentional divergences are documented; extensions are implemented in targeted, verifiable ways.

Details: technical TODO ↗ · async and distribution roadmap ↗