Skip to content

[Release Epic] Ship the first commercial release with exact-head, migration, operability, and supply-chain evidence #953

Description

@seonghobae

Current evidence — 2026-08-20

At protected main@8dc746920c12988f082e914879d95e13c9693535:

A large PR count is not itself a defect, but a release is not credible when inclusion, supersession, dependency order, current-head checks, migration compatibility, and runtime limitations cannot be stated from one immutable manifest.

Release objective

Produce the first truthful, installable, supportable single-tenant managed/self-hosted GA candidate. Multi-tenant SaaS remains non-GA until #950 is complete. The release must work standalone; optional CWL connectors are capability additions, not hidden prerequisites.

Dependency backlog

This epic owns release integration and must not duplicate implementation bodies:

Not every P1/P2 issue must block the first GA profile. Before release, update this checklist with an explicit release_blocker, post_ga_committed, experimental, or not_planned decision and rationale for each dependency. Core security, data integrity, migration safety, standalone deployment, backup/restore, operability, licensing, and supported-database truthfulness cannot be deferred silently.

PR-queue release shaping

  1. Capture exact protected-main SHA, branch ruleset, required checks, and all open PR exact heads.
  2. Classify every PR:
    • unique in-scope release change;
    • stack dependency;
    • superseded/duplicate;
    • contaminated aggregate requiring reconstruction;
    • experiment/post-GA;
    • blocked by an organization control-plane issue.
  3. Close duplicates with links to the canonical issue/PR; do not transfer stale-head review evidence.
  4. Rebase/update bounded stacks in dependency order without force-pushing over concurrent agent work.
  5. For every release PR, resolve valid review findings, run current-head checks, obtain qualifying approval, and merge through normal protection.
  6. Refresh docs/product-technical-gap-baseline.md after each integration wave.
  7. A release-cut branch/tag may be created only from protected main, never from an unreviewed feature aggregate.

Required release evidence

Product journey

A clean environment must prove, through browser/API tests:

OIDC/local approved login
→ project creation
→ encrypted authorized PostgreSQL connection
→ asynchronous snapshot
→ ERD search/layout/annotation/saved view
→ diff and exports
→ read-only share/revocation
→ approved snapshot/history
→ backup and restore

If #949 is complete for the release, also prove the full governed migration workflow. Otherwise persistent apply stays disabled and the release notes must identify it as non-GA.

Database and upgrade

  • clean install on PostgreSQL 18 and supported compatibility matrix;
  • upgrade from the oldest supported 0.1.x schema through every Alembic revision;
  • downgrade/rollback policy or explicit irreversible-migration procedure;
  • ORM ↔ migration drift check producing no unreviewed DDL;
  • backup, point-in-time or logical restore, and application recovery rehearsal;
  • queue/job recovery after service restart;
  • data-integrity checks for encrypted DSNs, snapshots, views, annotations, shares, API keys, and migration metadata.

Quality

  • production statement coverage 100%; production branch coverage 100%; public API/docstring coverage 100%;
  • frontend component, interaction, CSS/design-token, accessibility, i18n consistency, button-action edge, browser E2E, and Storybook tests;
  • real PostgreSQL fixtures, not only mocks;
  • exporter parser validation and deterministic round trips;
  • fuzz/property tests at DSN, identifier, snapshot, DBML/DDL, import/export, and connector boundaries;
  • skipped/ignored tests inventoried with release-blocking rationale; no hidden GPU requirement for this product.

Security and compliance evidence

  • threat model and secure deployment guide;
  • OIDC/JWT, CSRF, CORS, share-link, API-key, SSRF/DNS-rebinding, TLS, upload/connector, rate-limit, audit, and secret-lifecycle tests;
  • CSAP and SOC 2 control crosswalk as an engineering evidence map, without claiming certification;
  • data classification, purpose/access controls, retention, export, deletion, legal hold, backup, and incident procedures;
  • no blanket PII masking that breaks legitimate schema work; use authorization, encryption, minimization of broadcast/telemetry, and audit.

Supply chain

  • reproducible backend/frontend/container builds;
  • dependencies/actions pinned according to repository policy;
  • SPDX or CycloneDX SBOM for each shipped artifact;
  • SLSA v1.2-compatible build provenance/attestation;
  • container and filesystem vulnerability results with reviewed exceptions;
  • source archive, OCI image digest, license inventory, notices, and artifact hashes;
  • signed tag/release and documented rollback.

Operability and support

  • liveness/readiness distinction and dependency-aware readiness;
  • OpenTelemetry traces, metrics, and structured logs with stable cardinality and no secrets/customer values;
  • SLI/SLO and capacity profile linked to [Performance Gap] Establish large-schema SLOs, workload benchmarks, and a measured Rust boundary #951;
  • dashboards/alerts for snapshot queue lag, failures/retries, connection acquisition, share abuse, migration attempts, and database saturation;
  • runbooks for secret loss/rotation, target outage, queue backlog, failed migration, backup restore, dependency incident, and compromised share/API key;
  • supported PostgreSQL/dialect/browser/deployment matrix;
  • administrator, developer, user, upgrade, backup/restore, and troubleshooting documentation;
  • customer-facing error messages always state a safe next action.

Release artifacts

  • synchronized backend/frontend/product version;
  • CHANGELOG.md release section with exact included PRs/issues and incompatible changes;
  • RELEASE_NOTES.md or GitHub Release describing GA, beta, experimental, and disabled capabilities;
  • immutable release manifest containing source commit, migrations, dependency locks, workflow provenance, SBOM, image digest, test/benchmark receipts, Figma file ID, and known limitations;
  • OCI images and source distribution/install instructions;
  • published GitHub Pages documentation only if the release references a documentation site.

Acceptance

References — APA 7th

International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2022). Software, systems and enterprise—Architecture description (ISO/IEC/IEEE 42010:2022). https://www.iso.org/standard/74393.html

National Institute of Standards and Technology. (2022). Secure software development framework (SSDF) version 1.1 (NIST Special Publication 800-218). https://doi.org/10.6028/NIST.SP.800-218

SLSA Community. (2025). Supply-chain levels for software artifacts specification, version 1.2. https://slsa.dev/spec/v1.2/

World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancearea: securitySecurity boundary, hardening, or vulnerability preventionpriority: mediumNormal-priority or P2 workscope: commercial-readinessProduction, enterprise, release, or commercial readinessstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capability

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions