HHY Roadmap
Language and VM Evolution Roadmap
Five releases from v1.2 to v2.0, with recommended windows, delivery boundaries, and entry gates.
Five-release evolution overview
Released foundation
v1.0.0Released
Core semantics frozen
Pipe / Value / Stream / Error, 94 core callables, and three-platform release evidence
v1.1.0Released
Local process extensions
install/list/remove, Protocol 1, database 0.2.0, and three-platform release evidence
Five future releasesEnter sequentially through acceptance gates
Protocol and Office validation
- Stream / cancel / handle lifecycle
- Official Office extension stress validation
- Capability and cleanup closure
Database resource model
- Connection handles and pools
- Streaming queries with backpressure
- Type mapping and transaction hardening
Package distribution and tooling
- Signature and publisher verification
- Dependency resolution and remote index
- Offline lock and reproducible install
Long-term Runtime hardening
- Trace / profile / debug hooks
- Performance baseline and compatibility matrix
- Fuzzing, fault injection, and stress tests
Ecosystem and ABI decision
- Measure protocol limits with real integrations
- Evaluate embedding / FFI
- Publish a Native ABI only if necessary
Evolution principles1Freeze semantics before opening extensions2Make it usable and measurable before fast3Extend through protocol, not a second language model4Evaluate ABI only after Runtime stability
Release lineage, timing, and acceptance gates
| Release | Recommended window (not committed) | Primary delivery | Required before the next stage |
|---|---|---|---|
| v1.0.0 · Released | 2026-08-25 | Core language and VM semantics frozen | Pipe, Value, Stream, Error, the core standard library, and three-platform release evidence completed |
| v1.1.0 · Released | 2026-08-26 | Local process extensions and the official database extension | Install/load integrity, synchronous Protocol 1 calls, database 0.2.0, and three-platform release evidence completed |
| v1.2 | 2026 Q4–2027 Q1 | Protocol completion and official Office validation | Stream credit, cancellation, opaque-handle lifecycle, and capability paths survive large-workbook stress tests |
| v1.3 | 2027 Q2 | Database resource model | Connection handles/pools, streaming queries, type mapping, and transactions have bounded resources and regression coverage on PostgreSQL and MySQL |
| v1.4 | 2027 Q3 | Package distribution and engineering toolchain | Signature verification, dependency resolution, remote index, offline lock, and reproducible installation have a security review and rollback design |
| v1.5 | 2027 Q4–2028 Q1 | Runtime observability and long-term hardening | Trace/profile/debug hooks, performance baselines, fuzzing, fault injection, and the compatibility matrix pass continuously |
| v2.0 | 2028 H2 at the earliest | Ecosystem opening and ABI decision | At least two real integrations prove the process protocol insufficient; otherwise retain the process protocol and do not publish a Native ABI |
Evolution principles
| Principle | Constraint |
|---|---|
| Freeze semantics first | Stabilize Pipe, Value, Stream, Error, and cancellation semantics before broadening the ecosystem surface |
| Usable and measurable before fast | Every capability needs deterministic errors, resource bounds, and cross-platform tests before optimization |
| Protocol first | Integrate third-party capability through the Process Extension Protocol instead of inventing a second language model |
| ABI only when justified | Evaluate a Native ABI only after Runtime stabilization and measured need; choosing not to publish one is a valid result |
Review the roadmap once per quarter. Only unfrozen releases may move; scheduling changes must not weaken published semantics, compatibility commitments, or migration paths.
Explicit non-commitments
- No second Pipe, Stream, or Error model merely to justify a release number.
- No public exposure of internal Runtime C structures without a compatibility strategy.
- No use of recommended windows as a reason to skip testing, security, or cross-platform validation.
- No simultaneous rush into a remote registry, Native ABI, and multiple official extensions before stage gates pass.