v1.7.1 acceptance history and major-release plans for atomic state, shared memory across workers, coroutines and distributed transactions.
1.7.1 controlled concurrency and atomicity
This release fixes resource lifetimes and delivers seven experimental APIs, disabled by default. Review state ownership, cooperative file locks, strict transactions and bounded-task guarantees before enabling them.
1.7.1 passes local tests, four-platform CI and release validation. Language specification 1.0 remains frozen. Official sample, HTML and macOS/Linux Database 1.0.0 extensions are verified compatible. VS Code 0.2.0 and Sublime 0.1.0 retain independent versions; syntax and editor contract checks pass.
HIR, six optimization passes, integer MIR, type-feedback guards/deopt and local List scalar replacement are implemented. Explicitly enable HHY_COMPILER=ir, HHY_FEEDBACK_SPECIALIZATION=1 and HHY_SCALAR_REPLACEMENT=1; direct Bytecode remains default. Real workloads have not met default-enablement benefit gates. Scalar replacement retains original GC/quota reservations.
Versioned JSON diagnostics, Contract Registry JSON, a minimal LSP, and a VS Code editing loop
v1.1.8Completed
2026-08-31
Gradual Runtime governance
First module boundary, internal ownership API, sanitizer/GC stress, and a blocking performance-regression gate
v1.2.x3 releases+
Release
Release date
Main changes
Acceptance status
v1.2.0Released
2026-08-31
Official extension distribution and signing
Namespaced identities, Ed25519-signed index and package descriptors, deterministic resolution, dry runs, and transaction-safe installs
v1.2.1Released
2026-09-01
Locking, offline installs, and safe rollback
The same lock produces the same graph; offline rebuilds work; failed upgrades preserve the old environment
v1.2.2Released
2026-09-01
Official HTML complex-extension validation
Real fixtures, observable truncation, structured errors, and four-platform distribution all pass
v1.3.x15 releases+
Release
Release date
Main changes
Acceptance status
v1.3.0-alphaPrereleased
2026-09-01
Bytecode compiler skeleton
Core syntax compiles, invalid Bytecode is rejected, and AST remains the default engine
v1.3.0-betaStage gate complete
Merged into v1.3.0
Bytecode VM execution core
The execution bridge, verifier, resource boundaries, and full dual-engine fixtures passed acceptance
v1.3.0-rcStage gate complete
Merged into v1.3.0
Performance, profiler, stack trace, and default-switch gates
Three-platform and failure evidence is complete; the CPU benefit gate failed, so AST remains the default
v1.3.0Released
2026-09-01
Opt-in production Bytecode path
The full suite passes both engines; the performance decision retains AST as default with explicit fallback
v1.3.1Released
2026-09-01
Real-workload compatibility hardening
The official workload dual-engine matrix and capability evidence passed three-platform CI
v1.3.2Released
2026-09-01
VM internal-boundary stabilization
Versioned Bytecode Runtime boundary, static governance, and continuous AST oracle
v1.3.3Completed
Merged into v1.3.5
Native Opcode execution
Normal Bytecode execution no longer calls the AST evaluator; full dual-engine semantics pass
v1.3.4Completed
Merged into v1.3.5
VM data-path optimization
1M CPU workload ratio is 0.6805 with no material short-script or JSON/I/O regression
v1.3.5Released
2026-09-01
Bytecode default engine
run, profile, and shorthand default to Bytecode; AST remains the permanent oracle and explicit fallback
v1.3.6Released
2026-09-01
Stream Int fusion performance closure
Provably safe shapes fuse conservatively; unknown shapes fall back losslessly; dual-engine and cross-platform gates pass
v1.3.7Released
2026-09-01
Specialization hardening
Named metadata, unified stack/error rules, fallback reasons, and three-path differential gates pass
v1.3.8Released
2026-09-01
Compiler/Verifier optimization IR
Runtime does not inspect AST shapes; Stream Kernels verify independently and fall back safely
v1.3.9Released
2026-09-01
Profiler and resource consistency
Normal and observed execution share decisions; overhead, cancellation, and Heap-attribution gates pass
v1.3.10Released
2026-09-01
Bytecode cache governance
Five-workload evidence misses admission thresholds; no cache and no unverified external Bytecode
v1.3.11Released
2026-09-02
Runtime error-path hardening
Structured errors publish only after full construction; the original fuzz input is retained as a permanent regression
v1.4.x4 releases+
Release
Release date
Main changes
Acceptance status
v1.4.0Completed
2026-09-03
Web Runtime foundation
Embedding, one-time application loading, reusable handlers, and isolation gates complete
v1.4.1Completed
2026-09-03
Web MVP
HTTP/1.1, Router, Query/Header/Cookie, JSON APIs, and stable errors complete
v1.4.2Completed
2026-09-03
Web application capabilities
Middleware, static files, uploads, CORS, signed cookies, gzip, and reload complete
v1.4.3Released
2026-09-03
Streaming and multi-worker
SSE, Stream, large-file Range, processes, and observability complete; one million requests with zero failures
v1.5.x1 release+
Release
Release date
Main changes
Acceptance status
v1.5.0Released
2026-09-07
Database 1.0.0 and Runtime resource integration
Pools, remote TLS, transactions, cursors, exact types, cancellation and worker isolation; dual-database/engine and release Actions pass; RDS validation pending
v1.6.x4 releases+
Release
Release date
Main changes
Acceptance status
v1.6.0Evaluated
2026-09-08
Instruction selection and dispatch profiles
Versioned opcode/pair/triple metrics and switches ship in v1.7.0; superinstructions did not meet admission gates
v1.6.1Implemented
2026-09-08
Calls, closures and unwind
Compact call layout, closure paths and exception-region experiments pass differential checks; opt-in, shipped in v1.7.0
v1.6.2Evaluated
2026-09-08
Conditional inline caches
Map-slot experiment and stable/changing call-site evaluation completed; generic fallback retained, not admitted by default; shipped in v1.7.0
v1.6.3Evaluated
2026-09-08
GC, memory and scheduling decisions
Allocation/pause and scheduling demand evaluated; no new GC or async scheduler admitted; decisions delivered in v1.7.0
v1.7.x2 releases+
Release
Release date
Main changes
Acceptance status
v1.7.0Released
2026-09-08
Optimizing Compiler & Runtime
Four-platform CI and release validation pass; HIR, six passes, integer MIR, guards/deopt and local List scalar replacement ship opt-in
v1.7.1Current
2026-09-14
Resource ownership fixes and seven opt-in concurrency APIs. Remaining 1.7.x work stays subject to acceptance.
Passed local Release and ASan/UBSan suites, 69 engine/configuration cases, MySQL/PostgreSQL idempotency and unknown-commit reconciliation, a 120-second soak, 100,000-request Web test, four-platform CI and release validation. Seven experimental APIs remain disabled by default; a 24-hour soak, real power-loss testing and the complete fault matrix remain pending.
Future plans
The roadmap prioritizes atomicity, shared state, coroutines and distributed transactions, grouped by major release series. These are planned goals; unfinished capabilities are not guarantees of 1.7.1.
Major series
Goal
Milestones
Availability and acceptance
1.xStabilize existing capabilities
Stabilize the seven APIs and establish ownership, effect and resource contracts for shared state and coroutines.
Owner-bound atomic state → cooperative file updates → strict database transactions and bounded tasks; remove experimental gates separately after acceptance.
24-hour soak on the candidate build, fault matrix, AST/Bytecode parity, platform and resource validation; failed candidates remain experimental.
2.xAtomic state and coroutine kernel
Deliver domain-wide language atomicity, atomic shared-memory state across workers, and a coroutine scheduler.
Shared arena and generation handles → multi-object read/write sets and unified commit → resumable frames, nonblocking I/O and structured cancellation → integrated stabilization.
Transaction-history checks, crash recovery, GC roots, no lost wakeups, fairness, resource bounds and legacy-mode compatibility; stabilize the new language mode only after acceptance.
3.xDistributed transactions
Extend consistency to cross-node participants that support the transaction protocol.
Durable coordinator → prepare/commit/rollback adapters → UNKNOWN queries and recovery → high availability, fault injection and operational tooling.
Participant crashes, partitions, duplicate messages, decision logs and recovery; stabilize only validated participant configurations, with infrastructure still explicitly configured.
Disabled feature
When it becomes available
Meaning of availability
Seven existing experimental APIs
During 1.x stabilization, separately after acceptance for state, files, databases and tasks.
Callable without HHY_CONCURRENCY_EXPERIMENTS; APIs remain explicit and ordinary variables keep their semantics.
Cross-worker atomic state and coroutines
Experimental first in 2.x; stable after joint correctness, recovery and resource acceptance.
The new mode becomes stable; existing programs do not automatically change sharing or scheduling semantics.
Distributed transactions
In 3.x after durable coordination and participant acceptance.
Stable APIs still require database/coordinator configuration and do not capture all external effects.
Compiler, cache and fusion candidates
No mandatory enablement release; each must pass real-workload benefit, compatibility and resource budgets.
May remain disabled indefinitely; implementation or correctness alone does not establish performance admission.
Release directions are not calendar commitments. In 1.7.1, HHY_CONCURRENCY_EXPERIMENTS=1 already enables the seven experimental APIs. Stable API availability and default optimization are separate decisions; missed gates delay admission without lowering thresholds.
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.
