Skip to content

Release Acceptance Checklist

Use this before tagging a customer-facing version. Checkboxes are a process, not proof that this repository already completed v1.0.0.

Engineering gate

  • [ ] Clean worktree on the release branch (no unintended dirty provenance)
  • [ ] go fmt ./... / gofmt -l clean
  • [ ] go vet ./...
  • [ ] go test ./...
  • [ ] go test -race ./... or record SKIPPED with reason
  • [ ] go build ./cmd/iqv-integration-api
  • [ ] Focused script suites for the platforms in the release
  • [ ] mkdocs build --strict -f mkdocs.en.yml
  • [ ] mkdocs build --strict -f mkdocs.tr.yml
  • [ ] python scripts/docs/assemble_pages_site.py
  • [ ] python scripts/docs/check_bilingual_structure.py

Package gate

  • [ ] Version string matches the intended tag (vX.Y.Z)
  • [ ] .\scripts\release\build-release.ps1 -Version vX.Y.Z completed on a clean worktree
  • [ ] Four archives exist with the standard names (*-windows-native-amd64.zip, *-windows-docker-amd64.zip, *-linux-native-amd64.tar.gz, *-linux-docker-amd64.tar.gz)
  • [ ] SHA256SUMS present and verified (sha256sum -c or Get-FileHash)
  • [ ] release-manifest.json lists all four artifacts; checksums match disk
  • [ ] .\scripts\release\validate-release.ps1 -Version vX.Y.Z -RequireClean passes
  • [ ] Windows Native zip is source-based (has go.mod + install.ps1, no prebuilt exe)
  • [ ] Windows Docker zip has Dockerfile/compose and no .iqv-deployment / image tar
  • [ ] Linux Native has bin/iqv-integration-api and no go.mod
  • [ ] Linux Docker has image/*.tar and compose without build:
  • [ ] No .env, .git, secrets, or lab IPs inside archives

Lab gate (per shipped platform)

  • [ ] Clean install
  • [ ] /health/live and /health/ready
  • [ ] Host reboot recovery
  • [ ] Same-version NO-OP
  • [ ] Real update (new bytes/image)
  • [ ] ForceRedeploy where the product supports it
  • [ ] Controlled rollback (lab injection) or explicit deferral
  • [ ] Uninstall does not delete external MongoDB
  • [ ] Functional inbound POST with a real actor user (not a random ObjectID)
  • [ ] Security checks: no secret in logs/status/compose config output

Publication gate

  • [ ] CHANGELOG / release notes match implemented behavior
  • [ ] Tag and binary APP_VERSION / ldflags version agree
  • [ ] GitHub Pages built from MkDocs (Settings → Pages → GitHub Actions)
  • [ ] No private IPs, actor ObjectIDs, or credentials in public docs

Tagging v1.0.0 and pushing it is an operator Git step. Packaging readiness is implemented; a published GitHub Release exists only after that tag workflow succeeds.