release-datafusion-ducklake

name	release-datafusion-ducklake
description	Prepare and publish a new release of datafusion-ducklake to crates.io
disable-model-invocation	true
argument-hint	[version]
allowed-tools	Bash(cargo check*), Bash(cargo build*), Bash(git checkout*), Bash(git pull*), Bash(git log*), Bash(git status*), Bash(git add*), Bash(git commit*), Bash(sleep*)

Release datafusion-ducklake

Prepare and publish a new release. The user may provide a version number as $ARGUMENTS.

Step 1: Determine version

• If a version was provided ($ARGUMENTS), use it. Strip a leading v if present (e.g. v0.0.7 -> 0.0.7).
• If no version was provided, read the current version from Cargo.toml and suggest the next patch bump. Ask the user to confirm or provide a different version.

Step 2: Ensure clean, up-to-date main branch

• Confirm we're on main and the working tree is clean (git status).
• Pull latest: git pull.
• If the branch is dirty or not on main, warn the user and stop.

Step 3: Create release branch

• Create and switch to a new branch: git checkout -b release/v{VERSION}

Step 4: Bump version

• Update version in Cargo.toml (the [package] section, NOT workspace members).
• Run cargo check to regenerate Cargo.lock with the new version.
• Verify both Cargo.toml and Cargo.lock reflect the new version.

Step 5: Update CHANGELOG.md

• Read CHANGELOG.md and the git log since the last tag (git log $(git describe --tags --abbrev=0)..HEAD --oneline).
• Add a new ## [VERSION] - YYYY-MM-DD section at the top (below the header), categorized as Added/Changed/Fixed per Keep a Changelog format.
• Add a comparison link at the bottom: [VERSION]: https://github.com/hotdata-dev/datafusion-ducklake/compare/v{PREV}...v{VERSION}
• Ask the user to review the changelog entries before committing.

Step 6: Update README.md if needed

• Check if README.md references a version number (e.g. in dependency examples). If so, update to the new version.

Step 7: Commit and push

• Stage Cargo.toml, Cargo.lock, CHANGELOG.md, and README.md (if changed).
• IMPORTANT: Both Cargo.toml AND Cargo.lock must be committed. Missing the lock file will break the deploy.
• Commit with message: chore(release): prepare v{VERSION}
• Push the branch: git push -u origin release/v{VERSION}

Step 8: Create PR

• Create a PR with gh pr create targeting main.
• Title: chore(release): prepare v{VERSION}
• Body should note the version bump and link to the changelog.

Step 9: Merge PR, tag, and trigger release

After creating the PR, ask the user if they'd like to wait for CI or merge now.

When the user is ready, merge the PR:

gh pr merge --squash --delete-branch

Then checkout main, pull, tag, and push:

git checkout main && git pull

Verify the merged changes are present (the new version should be in Cargo.toml). If not, stop and warn the user.

git tag v{VERSION} && git push origin v{VERSION}

Step 10: Link to pending deployment

After pushing the tag, wait a few seconds, then fetch the workflow run triggered by the tag:

gh run list --workflow=release.yml --limit=1 --json databaseId,status,url

Extract the run URL and print it for the user:

Tag v{VERSION} pushed. Release workflow started.

Approve the deployment here: {RUN_URL}

After approval and deployment:

• Confirm the new version on crates.io
• Confirm docs update on docs.rs (may take up to a day due to build queue)