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 leadingvif present (e.g.v0.0.7->0.0.7). - If no version was provided, read the current version from
Cargo.tomland 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
mainand 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
versioninCargo.toml(the[package]section, NOT workspace members). - Run
cargo checkto regenerateCargo.lockwith the new version. - Verify both
Cargo.tomlandCargo.lockreflect the new version.
Step 5: Update CHANGELOG.md
- Read
CHANGELOG.mdand the git log since the last tag (git log $(git describe --tags --abbrev=0)..HEAD --oneline). - Add a new
## [VERSION] - YYYY-MM-DDsection 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.mdreferences 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, andREADME.md(if changed). - IMPORTANT: Both
Cargo.tomlANDCargo.lockmust 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 createtargetingmain. - 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: