mz-dbt-release

Automates dbt-materialize PyPI release PRs by bumping versions and dating the changelog.

6.4k|512|Updated Feb 22, 2019
One-click install
npx skills add https://github.com/MaterializeInc/materialize --skill mz-dbt-release
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: mz-dbt-release
Source: https://github.com/MaterializeInc/materialize/tree/main/.agents/skills/mz-dbt-release
Command: npx skills add https://github.com/MaterializeInc/materialize --skill mz-dbt-release

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Cutting a dbt-materialize release is a mechanical but error-prone chore: two version strings must stay in sync, the CHANGELOG must be dated correctly, and the release PR must follow a strict branch/commit/PR convention. This Skill encodes that entire procedure so nothing is missed.

Core Features & Use Cases

  • Synchronized version bumps: Updates __version__.py and setup.py together, with rules for when to bump patch versus minor (minor tracks the required dbt-postgres minor).
  • CHANGELOG dating: Inserts a dated ## X.Y.Z - YYYY-MM-DD heading under ## Unreleased without rewriting existing bullets, and cross-checks git log so no shipped commit is silently missing from the changelog.
  • Standardized release PR: Creates the dbt-release-X.Y.Z branch, a dbt-materialize: release vX.Y.Z commit, and a PR with a Ship: <url> body targeting MaterializeInc/materialize:main.
  • Use Case: A maintainer merges a feature PR into the dbt adapter and asks for the next release; the Skill verifies the unreleased changelog entries, bumps 1.9.9 to 1.9.10, and opens the release PR in one pass.

Quick Start

Ask the assistant to cut a new dbt-materialize release for the feature PR you just merged, and it will bump the version, date the changelog, and open the release PR.

Frequently Asked Questions about mz-dbt-release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I cut a dbt-materialize release?

Bump the version in `__version__.py` and `setup.py`, insert a dated heading under `## Unreleased` in CHANGELOG.md, then commit on a `dbt-release-X.Y.Z` branch and open a PR with a `Ship: <url>` body. PyPI publication is handled by CI after merge.

How do I choose the next dbt-materialize version number?

Default to bumping the patch component, such as 1.9.9 to 1.9.10. Only bump the minor component when upgrading to a new dbt-postgres minor, for example 1.9.x to 1.10.0. Read the current version from `__version__.py`.

Which files change in a dbt-materialize release PR?

Exactly three files: `dbt/adapters/materialize/__version__.py`, `setup.py`, and `CHANGELOG.md`, all under `misc/dbt-materialize/`. A `git diff --stat` showing a fourth file means the change has gone off-script.

What if a commit is missing from the dbt-materialize changelog?

Cross-check `git log <prev-release-sha>..HEAD -- misc/dbt-materialize/` against the `## Unreleased` section. If a commit touched the adapter but is not represented in the changelog, stop and ask whether it should be included rather than inventing an entry.

Do I need to run tests or cargo checks for a dbt release PR?

No. The release PR touches only Python version strings and Markdown, so cargo checks and test suites are skipped. `bin/fmt` and `bin/lint` are optional unless you accidentally made a wider change.