# lidarslam_ros2 v0.9.0

The stable product-foundation release candidate. v0.9.0 preserves the
documented rosbag2-to-Autoware-compatible map workflow and makes every
remaining v1.0 gate explicit, machine-readable, and fail-closed.

This candidate is not v1.0 and does not claim that ROS apt distribution or
independent adoption is complete. The release workflow publishes v0.9.x as a
normal GitHub Release—the stable candidate channel—while versions below v0.9
remain prereleases.

## Supported product path

The maintained installed interface remains:

```bash
lidarslam-map doctor /data/bag
lidarslam-map run /data/bag --output-dir /data/map
lidarslam-map inspect /data/map
```

The fixed Docker demo and source quickstart exercise the same profiles and
verification core. `view` is optional; `migrate-manifest` and
`rollback-plan` remain advanced recovery tools. No new beginner entrypoint
was added.

## What v0.9 adds

### One authoritative v1 readiness audit

`python3 scripts/check_v1_readiness.py` validates all ten product gates,
their evidence paths, the independent-user ledger, root version, and immutable
tag state. `--require-complete` rejects any missing gate instead of inferring
readiness from a narrower CI result.

At candidate preparation time the audit is honestly `NOT_READY: 6/10`.
Distribution, first tagged rollback evidence, three-user adoption, and
publication remain open.

### Release-ready ROS dependency boundary

The official PRBonn RKO-LIO `0.3.2-1` binary passed the pinned MID-360
installed golden-path E2E on both Humble and Jazzy. The product therefore
declares `rko_lio >= 0.3.2`; normal apt installation still waits for that
version to reach the main repositories.

The pinned `ndt_omp_ros2 0.1.0` candidate is locally ready at
`8b77fa5a6cdcad45bf35918361c892b6d94a287e`. Its read-only preflight checks
the parent gitlink, source branch, metadata, CMake exports, Bloom gate, source
tag, release repository, and both rosdistro entries. Network or API failures
are `BLOCKED`, never treated as missing publication artifacts.

### ROS apt installation and upgrade evidence

The manual package-manager workflow is ready for the first public builds. On
Humble and Jazzy it:

- installs the exact four product Debian versions;
- verifies `ndt_omp_ros2 >= 0.1.0` and `rko_lio >= 0.3.2`;
- validates the installed CLI, resources, schemas, completion, and historical
  node from `/opt/ros/<distro>`;
- compares package-owned paths across a main-to-testing upgrade and rejects
  stale files;
- runs and validates the pinned public MID-360 map with the installed apt
  product.

The workflow is manual until packages exist, so its presence is not presented
as execution evidence. Its exact source ref, version, apt channel, and mode
are encoded in the public workflow run name. The live v1 audit requires the
main-channel clean-install identity and successful Humble/Jazzy jobs before
the distribution gate can complete.

### Release and recovery integrity

The tagged workflow builds exact Humble/Jazzy image digests, checks the
installed CLI and source revision, verifies SBOM, BuildKit provenance, and
GitHub attestations, then performs conflict-safe immutable promotion. The
release bundle contains a schema-validated SHA-256 inventory.

Before a tag exists, the main CI job now builds that curated bundle twice from
the clean candidate commit, reopens both archives with the publication
verifier, checks every manifest size and hash, requires byte-identical output,
and retains the verified rehearsal artifact. This catches source-inventory or
reproducibility failures before the immutable tag is created.

Each published image produces `release-image-<distro>.json` and a
digest-pinned `rollback-plan-<distro>.json`; `release-promotion.json` proves
that moving a conflicting version tag is forbidden. The first successful tag
run then performs an independent read-only audit of the tag, stable release,
all six assets, cross-file identities, every bundled file hash, and the live
Humble/Jazzy GHCR version-tag digests. That publication and audit completed
successfully on 2026-07-31; the exact workflow, tag, and recovery assets are
preserved in the
[published-release evidence](../evidence/published-release-v0.9.0-2026-07-31.md).

## Research changes remain isolated

The oriented appearance matcher now supports extensible, separate intensity
and height correlations for radarless degeneracy studies. Tunnel and fog
holdouts showed that the channel gap was not reliable enough for automatic
selection. The adapters therefore remain default-off and do not change the
golden-path registration or correction policy.

## Dataset-specific voxel compatibility

The existing `legacy_voxel_downsample` option now restores both passes of the
pre-v0.3 voxel pipeline. This fixes the Newer College Maths-Hard regression
without adding an option or changing the modern default. On the clean
candidate, Maths-Hard improved from 0.140755 m to 0.081247 m APE; NTU VIRAL
and both RTK-SLAM Construction profiles reproduced their preceding clean
accuracy values exactly.

All five blocking release profiles passed from the same clean candidate commit,
and the Leo Drive map passed Autoware compatibility verification. See the
[voxel compatibility and release-gate evidence](../evidence/rko-voxel-compatibility-2026-07-31.md).

## Upgrade notes

- The public CLI and output schemas retain the v1 compatibility contract.
- Upgrade from a source-built v0.6.0 prefix has already passed fresh-prefix
  parity on Humble and Jazzy.
- A real Debian main-to-testing upgrade must be captured after both versions
  exist in ROS apt; do not substitute the source-prefix result for that gate.
- Use a new output directory for every mapping run. Existing outputs remain
  immutable.

## Known release blockers

- `ndt_omp_ros2 0.1.0` still needs its source tag, release repository, Bloom
  tracks, and Humble/Jazzy rosdistro entries.
- Required binary dependencies and lidarslam packages must sync to the normal
  ROS apt repositories before the apt command becomes a supported beginner
  path.
- The first tagged release must publish and verify its rollback assets.
- Three distinct independent users must complete the documented first-map
  validation. The tracked ledger remains 0/3.

Authoritative status and procedures:

- [v1.0 readiness](../v1-readiness.md)
- [Distribution and installed CLI](../distribution.md)
- [rosdistro release runbook](../rosdistro-release.md)
- [Operational reliability](../operational-reliability.md)
- [v0.9 product roadmap](../roadmap/v0.9.md)