# v0.97.0 — Monitoring, Assurance & Packaging

> **Status:** Planned
> **Scope:** Large
> **User promise:** *"I can monitor, verify, install, and upgrade the supported build."*
> **Blocked by:** [v0.96.0](v0.96.0.md)
> **Renumbered:** previously v0.94.0. This is the final feature release.

## Theme

Finish the monitoring contract, run release assurance on one candidate commit,
and prove that each supported package can install and upgrade. After this
release, CI enforces the feature freeze.

The 72-hour soak is a release gate. A separate longevity environment looks for
problems that take longer than one release run to appear. Package readiness is
based on reproducible artifacts and smoke tests, not a third-party repository's
acceptance schedule.

## Items

### PP-5: Monitoring integration

- Prometheus exposes the full stable metric set. A shipped Grafana dashboard
  and alert rules cover SLA breach, suspension, CDC lag growth, disk trend,
  repeated FULL fallback, external graph refresh failures, output-delta
  consumer lag, and backlog growth.
- CI validates OpenTelemetry spans from v0.81.0 against a real collector. Span
  names and attributes are a documented compatibility surface.
- `health_check()` remains the single operational health entry point and has a
  stable schema suitable for automation.

### PP-7: Soak, compatibility, and regression gates

- **Release soak:** Run 72 hours across multiple databases with schema changes,
  restarts, injected failures, mixed freshness targets, external graph
  refreshes, and output-delta consumers. Require zero result deviations and no
  unbounded memory, disk, retained-output, or catalog growth.
- **Upgrade matrix:** Run every pair in the bounded v1.0 support manifest from
  v0.92.0 with an active workload and real old binaries. For v1.0, this is
  v0.40.0 through the latest v0.98.x release on PostgreSQL 18.
- **Performance gates:** Enforce refresh throughput, write-path impact,
  graph-refresh overhead, output-log amplification, TPC-H/Nexmark latency,
  memory, WAL, and CPU regression budgets.
- **Real workloads:** Run representative application schemas and query shapes
  continuously so isolated benchmarks do not define release readiness.

The 72-hour soak and upgrade matrix must pass on the same candidate commit.

### PP-7b: Longevity environment

Keep at least one longer-lived deployment running across candidate builds. It
tracks catalog and retained-state growth, memory creep, repeated repair cycles,
long-horizon scheduler behavior, WAL amplification, output-delta retention,
and disk amplification.

The environment informs release readiness. It does not synchronously block
every commit.

### PP-8: Packaging and install experience

Produce each supported package reproducibly, then run install and upgrade smoke
tests that create and refresh a stream table. Publication automation must be
ready for PGXN, apt/rpm via PGDG, Docker/GHCR, CloudNativePG, and source builds.

Third-party repository acceptance may complete asynchronously. It does not
delay the internal feature freeze when the artifact, smoke tests, and
publication automation are ready.

## Exit criteria

- [ ] Grafana dashboard and alert rules ship with tests. CI validates OTel
      against a real collector
- [ ] Graph V1 and Delta V1 conformance suites pass against the packaged build
- [ ] The 72-hour soak and every pair in the bounded v1.0 upgrade matrix pass on
      the same candidate commit
- [ ] Performance regression gates cover throughput, median, p95, and p99 where
      useful, memory, WAL, CPU, output-log amplification, and foreground write
      impact
- [ ] The longevity environment reports no unexplained cumulative growth or
      repeated recovery loop
- [ ] Every supported artifact builds reproducibly and passes install and
      upgrade smoke tests
- [ ] Publication automation is ready. External repository acceptance is
      tracked separately
- [ ] CI enforces the feature freeze after this release
