CREXX 1.0.0 Beta 3 Release Notes

Status: work-in-progress planning note for develop. Target tag: v1.0.0-beta.3. Do not describe beta 3 as released until that tag and its release assets exist. Created: 2026-06-17, after the v1.0.0-beta.2 tag.

CREXX 1.0.0 beta 3 is planned as the Release 1 foundation beta after the beta 2 close-out. It should convert the beta 2 hardening work into the branch state needed for Release 1 design lock, foundation decisions, package validation, and final feature completion.

Timetable

Date	Milestone	Beta 3 meaning
2026-06-17	Beta 3 opens on develop	Version strings, README, docs index, and planning notes move to beta 3 WIP while beta 2 remains the latest completed beta tag.
2026-07-03	Design lock	Level B/G split, plugin policy, UTF ownership, Level C MVP, GPU/threading scope, and issue owners/labels are approved.
2026-07-31	Beta 3 foundation target	High-risk VM/compiler foundations either land with tests or move out; beta 3 package status, known limitations, and release assets are checked against the tag.
2026-08-14	Feature complete after beta 3	User-facing Release 1 surface is frozen except for release defects, documentation, QA, examples, packaging, and measured performance work.

Planned Scope

Beta 3 should focus on a smaller, more explicit Release 1 contract rather than new broad language surface:

• Level B lockdown: finish tests and documentation for the stable Level B syntax, library surface, UTF/binary rules, references, arrays, collections, interfaces/classes, ADDRESS, TRACE, imports, linking, and packaging.
• Level B/G split: publish the Release 1 boundary between stable Level B and the initial Level G library overlay.
• UTF and text ownership: keep .string as valid UTF-8, .binary as arbitrary bytes, and move richer Unicode work into Level G library planning.
• Plugin and package policy: classify plugin directories, align default build/package contents, and make optional or experimental pieces obvious.
• VM/compiler foundations: harden late load/relink behaviour, indexed lookup, large immutable constants, and the measured optimizer work needed by approved Release 1 demos.
• RexxScript milestone: define and, if practical, demonstrate the next interpreted strings-only RexxScript slice. RexxScript is not the Level C compiler path, but it may share BIF implementations where that is clean.
• Level C milestone: keep parser/highlighter support visible and include the approved narrow canonical-AST lowering proof. Level C is compiled Classic Rexx, implemented by transforming the Level C parse/AST shape into the canonical compiler AST shape; the beta 3 proof is an executable tracer spine, not broad Classic Rexx compatibility.
• Packaging: keep portable ZIP assets, continue macOS .pkg and Linux .deb hardening, and add the signed Windows NSIS installer only if the build, signing, and upload flow is reliable before the beta 3 tag.
• Demos, tutorials, and performance: curate examples and establish performance baselines before claiming optimizer wins.

Implemented Foundation Work

The current develop branch includes the following beta 3 WIP foundations; they are not released until the beta 3 tag exists:

• byte-addressed binary memory, immutable binary constants, zero-copy compare, and packed jump tables with linear, open-hash, ACPH, and auto algorithms;
• conservative compiler lowering of eligible integer, string, and binary dispatch to packed jump tables, with measured profitability thresholds;
• sorted runtime interface method/factory registries that are rebuilt after late module loading, plus explicit-file late-load tests through both VM variants and the crexx driver;
• exact crexx -l paths when the argument contains a directory component, so applications can select an approved library file without runtime path search;
• declarative native-provider dependencies, static-first trusted runtime resolution, automatic native-package archive selection, explicit module initializers, and the process-reentrant standard/default rx_hash provider exposing the compatible one-shot rxhash.sha256() plus canonical lowercase hex, immutable pointer-free incremental state, and synchronous bounded-memory file SHA-256 to Level B and Level G; and
• initial Level G structured concurrency, including task/parallel syntax, explicit pool and scope classes, local and isolated-process execution, bounded byte endpoints, structured child-process redirects, and a concurrent HTTP client/server shared by the LLM providers. This surface has local macOS qualification; Linux/Windows conformance, package proof and an explicit publication decision remain open.

Cross-platform QA, the central beta 3 performance baseline, package validation, and final documentation review remain open release work.

SHA-256 public family

Beta 3 WIP stages the complete rx_hash SHA-256 family for both Level B and Level G:

rxhash.sha256(data = .binary) = .binary
rxhash.sha256hex(data = .binary) = .string
rxhash.sha256init() = .binary
rxhash.sha256update(state = .binary, data = .binary) = .binary
rxhash.sha256final(state = .binary) = .binary
rxhash.sha256finalhex(state = .binary) = .string
rxhash.sha256file(path = .string) = .binary
rxhash.sha256filehex(path = .string) = .string

Raw results are exactly 32 bytes; direct hexadecimal results are exactly 64 canonical lowercase characters. All .binary data is byte-preserving, including embedded NUL and invalid UTF-8. Incremental state is an immutable, copyable and transferable 152-byte version-1 value: canonical big-endian header/count/chaining fields and zero-padded pending bytes are protected by an integrity digest, with no pointer, C padding or host-endian representation. Updates return a new state, empty updates are valid, and finalization is repeatable. Invalid length/magic/version/format/invariants/integrity raise INVALID_ARGUMENTS before hashing.

File procedures synchronously read binary files in fixed 32 KiB chunks and do not accumulate the whole file. Open, read and close failures raise NOTREADY with the failed stage; path selection, connector and cancellation policy, and application size ceilings remain caller responsibilities. The dynamic provider autoload and static/native package-selection contract is unchanged. For example, callers can use sha256hex(data), retain the new value from each sha256update(state, chunk) before sha256finalhex(state), or call sha256filehex(path) when synchronous path hashing is appropriate. The full state layout, signal contract, and examples are in Binary hashing with rxhash.

Out Of Scope For Beta 3

• A final Release 1 stable contract.
• Full Classic Rexx / Level C runtime compatibility.
• Full Level G Unicode or broad Level L syntax sugar.
• Stable GPU integration, shared writable VM state, detached tasks or public worker/thread identity.
• Windows MSI, WiX, or winget publication.

Expected Package Shape

The final package list must be checked against the v1.0.0-beta.3 tag assets. The intended beta 3 shape is:

• Linux x64: portable ZIP, with .deb promoted only if install/uninstall and dependency checks are reliable.
• Windows x64: signed portable ZIP, plus a signed NSIS setup.exe if the local signing flow can build, sign, upload, and verify it reliably.
• macOS arm64 and x86_64: portable ZIPs plus signed, notarized, stapled .pkg installers when Apple signing and notarization secrets are configured.

Known Limitations

• Beta 3 remains part of the Release 1 beta line. The Release 1 target remains end of August 2026.
• Level B is the main implemented language surface, but final Release 1 lockdown work is still pending.
• Level G has an implemented initial task/parallel surface and library overlay, not a full stable language contract. Syntax requires OPTIONS LEVELG and lowers through the public concurrency classes.
• Normal broad Level C compilation is not part of beta 3. The included Level C lowering proof is deliberately narrow and unsupported forms continue to fail closed.
• Concurrent task execution is initial and locally qualified on macOS; Linux/Windows conformance and packaging evidence are still required. It uses isolated worker-owned VM state rather than shared writable registers, globals or objects.
• Release package signing status, checksums, and final asset names must be checked against the actual beta 3 tag assets before publication.

Related Notes

• Beta 2 release notes remain available at v1.0.0-beta.2.md.
• The Release 1 plan is tracked separately in ../release-1-plan.md.
• The checked user examples and exact current limitations are in Concurrent programming and the concurrency worklist.