Version and Compatibility
The current website baseline is 0.9.8-RC1. It is a release candidate, and the new bloge-verification module is published as Preview; neither label should be read as a production certification or a promise that every integration surface is stable.
Checked release baseline
| Field | Value |
|---|---|
| Artifact version | 0.9.8-RC1 |
| Release channel | RC |
bloge-verification channel | Preview |
| Source repository declared by the release POM | https://github.com/leanowtech/bloge |
| Source commit | cc38fbe5bb79ccc603888e4307cfe566d4674ffc |
| Java baseline | Java 25 |
| Website dependency rule | Use ${bloge.version} in copy-paste Maven snippets |
The website pins its checked source submodule to the commit above. Exact version and commit references belong on release and compatibility pages; reusable dependency snippets use ${bloge.version} so the next release does not leave copy-paste instructions behind.
What to review when upgrading
| Surface | Review before upgrading |
|---|---|
| Java API | Method signatures, enum values, builders, exception contracts, and module dependencies |
| DSL syntax and semantics | Parser grammar, imports, expressions, dependency inference, branch behavior, and schema validation |
| Durable persistence | Checkpoint payloads, store contracts, Flyway migrations, lease/recovery behavior, and event journal schemas |
| Extensions | Session/state/agent checkpoint shape, graph hashes, signal behavior, and provider-owned compiler contracts |
| Tooling | Capability catalogs, LSP diagnostics, Maven goals, and lint rule IDs |
| Business verification | Scenario/Policy/Fixture schemas, VerificationStatus, evidence readers, trust levels, and claim gates |
bloge-verification compatibility boundary
bloge-verification consumes the real BLOGE parser/compiler/engine and customer OperatorRegistry, but executes under a controlled verification environment. Its report is about the declared Scenario contract and the evidence captured for that run. It does not by itself prove production database compatibility, network/container isolation, external approval identity, or that the business rule set is exhaustive.
The four result states are intentionally not interchangeable:
| State | Meaning |
|---|---|
PASS | The complete execution satisfied the declared business contract. |
FAIL | Execution completed, but a business expectation or governance threshold was not satisfied. |
INVALID | Scenario, Policy, Fixture, binding, or capability combination is invalid. |
INCOMPLETE | The run or evidence chain did not complete; it is not a business pass or fail. |
EvidenceTrust and ClaimCapability add evidence and decision context; they do not change the business verdict. Read BLOGE Verify before using verification output in a team or release gate.
Documentation rule
Every release-specific page should identify its source version, source commit, affected modules, breaking or behavioral changes, persistence implications, and the tests or conformance fixtures that support the claim. If a release note has not been confirmed by the release owner, this site only publishes the verified version/module baseline and links to the relevant capability page.