chore(release): prepare v0.1.0-beta.1

Author: robertvokac

CHANGELOG.md

@@ -9,6 +9,34 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). While the
 
 ## [Unreleased]
 
+## [0.1.0-beta.1] — 2026-08-22
+
+Sharp Runtime is complete for its currently declared practical subset and enters maintenance
+mode with this release. Compared with `0.1.0-alpha.1`, this beta closes the final internal audit,
+DateTime-kind propagation, and cross-compiler build-hygiene work without expanding the declared
+.NET compatibility scope.
+
+### Fixed
+
+- Reconciled all 364 historical audit findings against the implementation: **343 remediated**,
+  **19 accepted deviations**, **2 false positives**, and **0 open**.
+- Closed the remaining lifetime, arithmetic, undefined-behaviour, temporary-path, validator, and
+  selective-component coverage defects, with permanent regression tests.
+- Completed `DateTimeKind` propagation through `DateTime`, `DateTimeOffset`, `TimeZoneInfo`,
+  `TimeZone`, and XML conversion while preserving the documented practical-subset boundaries.
+- Restored warning-clean Clang builds, made the production Clang build a local and CI gate, and
+  retained the warning-clean GCC build.
+- Made Windows entropy chunking portable to i686 and restored hosted-runner component CI.
+
+### Verification
+
+- **17,840/17,840** tests pass across 38 executables, with 0 failed and 0 skipped.
+- The module graph is **41 modules / 96 edges**; all 10 selective component configurations pass.
+- GCC and Clang production builds complete with **0 warnings and 0 errors** under `-Werror`.
+- The Doxygen no-regression gate passes at the documented baseline of **2,675 warnings**.
+- Verified on Debian GNU/Linux 13 with GCC 14.2.0, glibc 2.41, CMake 3.31.6, tzdata 2026b,
+  and zlib 1.3.1.
+
 ## [0.1.0-alpha.1] — 2026-08-20
 
 First tagged release. Sharp Runtime has been developed continuously since 2025-05-30; this tag
@@ -84,5 +112,6 @@ instead. See [`docs/releasing.md`](docs/releasing.md).
   (`SHARP_RUNTIME_HAS_NATIVE_INT128`); they are absent on MSVC and 32-bit MinGW, which is a
   known, accepted and permanent boundary.
 
-[Unreleased]: https://github.com/openeggbert/sharp-runtime/compare/v0.1.0-alpha.1...HEAD
+[Unreleased]: https://github.com/openeggbert/sharp-runtime/compare/v0.1.0-beta.1...HEAD
+[0.1.0-beta.1]: https://github.com/openeggbert/sharp-runtime/compare/v0.1.0-alpha.1...v0.1.0-beta.1
 [0.1.0-alpha.1]: https://github.com/openeggbert/sharp-runtime/releases/tag/v0.1.0-alpha.1

CMakeLists.txt

@@ -9,7 +9,7 @@ project(SHARP_RUNTIME VERSION 0.1.0 LANGUAGES CXX C)
 # copy would keep an already-configured build directory reporting the previous release after a
 # bump -- exactly the kind of stale claim a release must not make. SHARP_RUNTIME_VERSION_STRING
 # is the single spelling the rest of the build reads. Do not re-derive it elsewhere.
-set(SHARP_RUNTIME_VERSION_PRERELEASE "alpha.1")
+set(SHARP_RUNTIME_VERSION_PRERELEASE "beta.1")
 if(SHARP_RUNTIME_VERSION_PRERELEASE)
     set(SHARP_RUNTIME_VERSION_STRING "${PROJECT_VERSION}-${SHARP_RUNTIME_VERSION_PRERELEASE}")
 else()

Doxyfile

@@ -48,7 +48,7 @@ PROJECT_NAME           = "sharp-runtime"
 # could be handy for archiving the generated documentation or if some version
 # control system is used.
 
-PROJECT_NUMBER         = 0.1.0-alpha.1
+PROJECT_NUMBER         = 0.1.0-beta.1
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer a

README.md

@@ -44,7 +44,7 @@ values.
 
 ## Version
 
-Current release: **0.1.0-alpha.1** (pre-release — the public API may still change; see
+Current release: **0.1.0-beta.1** (pre-release — the public API may still change; see
 [`CHANGELOG.md`](CHANGELOG.md) for what the release contains and
 [`docs/releasing.md`](docs/releasing.md) for how versions are managed). Compiled code reads its
 own version from `SharpRuntime::getVersionString()` in `SharpRuntime/Version.hpp`, a header the

docs/releasing.md

@@ -3,7 +3,7 @@
 
 # Releasing Sharp Runtime
 
-*Current as of 0.1.0-alpha.1 (2026-08-20).*
+*Current as of 0.1.0-beta.1 (2026-08-22).*
 
 Sharp Runtime follows [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html). A release
 is a git tag plus a `CHANGELOG.md` entry — there is no separate release branch, and nothing is
@@ -16,11 +16,11 @@ The version is decided in exactly **one** place:
 ```cmake
 # CMakeLists.txt (repository root)
 project(SHARP_RUNTIME VERSION 0.1.0 LANGUAGES CXX C)
-set(SHARP_RUNTIME_VERSION_PRERELEASE "alpha.1")   # empty on a final release
+set(SHARP_RUNTIME_VERSION_PRERELEASE "beta.1")   # empty on a final release
 ```
 
 `project(VERSION …)` accepts numeric components only, so the pre-release identifier sits beside
-it and the two are joined into `SHARP_RUNTIME_VERSION_STRING` (`0.1.0-alpha.1`).
+it and the two are joined into `SHARP_RUNTIME_VERSION_STRING` (`0.1.0-beta.1`).
 `SHARP_RUNTIME_VERSION_PRERELEASE` is deliberately a normal variable and not a cache entry: a
 cached copy would keep an existing build directory reporting the previous release after a bump.
 
@@ -63,7 +63,7 @@ Two copies are maintained by hand and must be updated as part of a bump:
 While the major version is 0, a minor bump may change the public API — which for this project is
 routine rather than exceptional: `docs/StandingApprovals.md` SA-2 governs public source breaks and
 they land with a migration note. Pre-release identifiers are `alpha.N` → `beta.N` → `rc.N`,
-ordered as SemVer orders them. `0.1.0-alpha.1` precedes `0.1.0`.
+ordered as SemVer orders them. `0.1.0-alpha.1` precedes `0.1.0-beta.1`, which precedes `0.1.0`.
 
 ## Downstream consumers
 
@@ -115,7 +115,7 @@ commit hash. Tagging is therefore worth doing before a downstream release, not a
 6. **Tag** with a `v` prefix and an annotated tag:
 
    ```bash
-   git tag -a v0.1.0-alpha.1 -m "Sharp Runtime 0.1.0-alpha.1"
+   git tag -a v0.1.0-beta.1 -m "Sharp Runtime 0.1.0-beta.1"
    ```
 
    The tag string carries the `v`; `SHARP_RUNTIME_VERSION_STRING` never does.
@@ -124,7 +124,7 @@ commit hash. Tagging is therefore worth doing before a downstream release, not a
 
    ```bash
    git push origin <branch>
-   git push origin v0.1.0-alpha.1
+   git push origin v0.1.0-beta.1
    ```
 8. **Open the next cycle** by adding an empty `## [Unreleased]` section back to `CHANGELOG.md` if
    step 2 consumed it.