Prepare release

Skill manuelmauro/arkouda/skills/prepare-release

AI-native CLI for Architecture Decision Records — built for AI coding agents

Install

npx -y skills add manuelmauro/arkouda --skill prepare-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Prepare a new arkouda release with changelog and version bumps

The file declares its own license as MIT OR Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.6 KB, as published. Nobody here has run it

Prepare Release

Steps to prepare a new arkouda release. Pushing a vX.Y.Z tag triggers .github/workflows/release.yml, which builds Linux x86_64, macOS aarch64, and Windows x86_64 binaries and attaches them to a GitHub release.

Checklist

make ci is green (fmt, clippy -D warnings, tests, build, arkouda check on docs/adr/)
arkouda check passes on the project's own ADRs
Update version in Cargo.toml
Update Cargo.lock (cargo check)
Update CHANGELOG.md
Find and update version references in docs
Commit changes (including Cargo.lock)
Create annotated git tag and push

Version Bump

Update version in Cargo.toml:

[package]
version = "X.Y.Z"

After updating Cargo.toml, run cargo check to refresh Cargo.lock:

cargo check

Changelog Format

Follow Keep a Changelog format. If CHANGELOG.md does not yet exist, create it for this release.

## [X.Y.Z] - YYYY-MM-DD

### Added
- New features

### Changed
- Changes to existing functionality

### Fixed
- Bug fixes

Update Version References in Docs

Search for hardcoded version numbers in documentation and update them:

# Find version references (e.g., [email protected], v0.1.0)
rg "arkouda@\d+\.\d+\.\d+" --type md
rg "v\d+\.\d+\.\d+" README.md

Common locations:

README.md — CI example (cargo install [email protected])
Installation instructions
Badge URLs

Release Commands

# Verify everything passes (mirrors what CI and lefthook run)
make ci

# Commit release changes
git add -A
git commit -m "chore: release vX.Y.Z"

# Create annotated tag
git tag -a vX.Y.Z -m "Release vX.Y.Z"

# Push commit and tag — pushing the tag triggers the release workflow
git push && git push --tags

The release.yml workflow handles the rest: cross-platform builds, sha256 checksums, and a GitHub release with generate_release_notes: true (so commit subjects since the previous tag become the release body).

Publishing to crates.io

The release workflow does not publish to crates.io — do it manually after the GitHub release is up:

# Dry run first
cargo publish --dry-run

# Publish
cargo publish

After release

Confirm the binary downloads on the GitHub release page work (curl -sSfL .../install.sh | sh should now pick up the new version).
If cargo publish succeeded, cargo install arkouda and cargo install [email protected] both reach the new version.