Skip to content

Release-readiness checklist

Use this checklist before distributing a paid or public version. Record the release version, owner, date, evidence links, and accepted risks in the release review. An unchecked blocker means the release is not ready.

Product and terms

  • [ ] Confirm the release scope, target buyer, included editions, deliverables, exclusions, and tested setup path.
  • [x] Resolve the software-license decision. Decided 2026-11-01 in decision 0001: source-available evaluation licence (LICENSE); production, client-delivery, and redistribution rights need a separate written licence. Third-party dataset terms stay separate from the software licence.
  • [x] Credit TheLook eCommerce in NOTICE. The Kit queries the dataset in place and ships no rows. Snowflake seeds and migration fixtures are labelled synthetic and contain no copied customer data.
  • [ ] Read the TheLook Marketplace listing's terms while signed in to Google Cloud and record the result in decision 0001. Until then, do not use TheLook results or screenshots in marketing or redistribute them.
  • [ ] Include LICENSE, NOTICE, and SUPPORT.md in each edition bundle.
  • [x] Publish a support policy. The baseline is best effort with no warranty or SLA (SUPPORT.md). A paid offer needs its own response target, duration, and escalation owner.
  • [ ] Publish an update policy: supported release line, update window, security-fix handling, and whether major updates are included or separately licensed.
  • [ ] State the supported Python, dbt Core, adapter, and warehouse versions; document known limitations.

Edition validation

  • [ ] Complete two independent clean-checkout installs with no maintainer intervention. Record edition, environment, elapsed time, errors, and support time.
  • [ ] BigQuery: run credential-free CI parse and an authenticated dbt build in an isolated dataset in the source-compatible location. Confirm model and data tests pass, inspect billed-byte estimates, and save run evidence.
  • [ ] Snowflake: run dbt parse and an authenticated dbt build with a non-production role, database/schema, and auto-suspending warehouse. Confirm seeds, models, and tests pass; inspect the CI target and suspend the warehouse after validation.
  • [ ] Confirm edition-specific profiles, dependencies, generated artifacts, and target schemas remain isolated.
  • [ ] Verify each edition's incremental example and its documented full-refresh path produce the intended result, or clearly exclude the example from release claims until warehouse execution is recorded.

Dependencies and security

  • [ ] Review each requirements.txt and regenerate its edition-specific universal Python 3.11 hash lock with the documented uv pip compile command. Commit each requirements/lock pair together; confirm CI installs with --require-hashes.
  • [ ] Scan locked Python dependencies for known vulnerabilities. Record scanner name/version, findings, remediations, and any accepted exception with an owner and review date.
  • [ ] Run secret scanning on the release tree and relevant commit history. Confirm profiles, keys, tokens, local .env files, warehouse logs, and customer data are absent; rotate any credential found in history.
  • [ ] Review CI trust boundaries: Snowflake pull requests parse without credentials; pushes to main run the credentialed build when required repository secrets are configured and the database/schema pass naming checks. This workflow gate does not enforce branch protection, which is unavailable on the current private plan. BigQuery CI uses short-lived credentials and targets its configured dataset.
  • [ ] Review database grants, warehouse size/auto-suspend settings, data retention, and cleanup instructions for the release's example environments.

Packaging and release record

  • [ ] Update CHANGELOG.md with user-visible changes, migrations, known issues, and edition-specific notes.
  • [ ] Confirm setup, first-run, operations, attribution, support, and update-policy links work in a clean checkout.
  • [ ] Inspect the release archive/tree and checksum using the archive audit. Include no private keys, profiles, .env files, dbt target/ or logs/ outputs, or real customer data.
  • [ ] Complete the release validation record with actual results and evidence; keep account-specific details private.
  • [ ] Product owner records the version, release date, validation evidence, unresolved non-blockers, and approval decision.

Product-owner decisions still required

  • Software license and commercial reuse terms: decided under owner delegation in decision 0001 (source-available; reversible to Apache-2.0 or MIT). Owner actions: confirm the legal name of the copyright holder in LICENSE and NOTICE, and replace the governing-law placeholder in LICENSE section 8.
  • TheLook data attribution and redistribution: decided: query in place, no redistributed rows, credit in NOTICE. Still open: whether screenshots or extracts may be redistributed, pending a signed-in read of the Marketplace listing terms.
  • Paid support and update entitlements: baseline is best effort with no SLA. For a paid offer, choose the support duration, response target, update window, and which changes require a separate purchase.
  • Versioning policy: choose the public versioning scheme and what constitutes a breaking change for the two independent editions.