# v0.94.0 — Monitoring, Assurance & Packaging > **Status:** Planned > **Scope:** Large > **User promise:** *"I can monitor, verify, install, and upgrade the supported build."* > **Blocked by:** [v0.93.0](v0.93.0.md) > **Renumbered:** previously v0.93.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, 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, and mixed freshness targets. Require zero result deviations and no unbounded memory, disk, 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.95.x release on PostgreSQL 18. - **Performance gates:** Enforce refresh throughput, write-path impact, 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, 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 - [ ] 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, 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