chore: bump version to 0.2.1

[IlyaGusev]

Release v0.2.1: the --query-time flag for point-in-time search (#65).

After merge, tagging v0.2.1 on main triggers the release workflow (binaries, installers, Homebrew tap), per RELEASE.md.

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Bump crate version to v0.2.1

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Bump keenable-cli crate version from 0.2.0 to 0.2.1.
• Align Cargo.toml and Cargo.lock for the v0.2.1 release tag workflow.

High-Level Assessment

The following are alternative approaches to this PR:

1. Use `cargo-release` for versioning + tagging

• ➕ Automates version bump, tagging, and optional changelog steps
• ➕ Reduces human error across Cargo.toml/Cargo.lock updates
• ➖ Adds a release tool dependency/process to learn
• ➖ May be overkill for infrequent releases

2. CI-enforced version consistency check

• ➕ Prevents mismatched versions from merging
• ➕ Keeps current lightweight manual release workflow
• ➖ Still requires manual bumps
• ➖ Adds minor CI maintenance

Recommendation: The PR’s approach (manual bump in Cargo.toml with matching Cargo.lock) is appropriate for a small, straightforward release. If releases become frequent or multiple crates are introduced, consider cargo-release or a simple CI check to prevent version drift.

Files changed (2) +2 / -2

Other (2) +2 / -2

Cargo.lockUpdate locked package version to 0.2.1 +1/-1

Update locked package version to 0.2.1

• Updates the 'keenable-cli' package version recorded in the lockfile from 0.2.0 to 0.2.1 to match the release.

Cargo.lock

Cargo.tomlBump crate version to 0.2.1 +1/-1

Bump crate version to 0.2.1

• Bumps the crate version in the package manifest from 0.2.0 to 0.2.1 for the v0.2.1 release.

Cargo.toml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Release docs version mismatch 🐞 Bug ⚙ Maintainability

Description

After bumping the crate to 0.2.1, RELEASE.md still instructs running cargo set-version 0.2.0 and
tagging v0.2.0, which can lead to cutting/pushing the wrong tag and producing a release that
doesn’t match the code’s declared version.

Code

Cargo.toml[3]

+version = "0.2.1"

Evidence

Cargo.toml declares version 0.2.1, but RELEASE.md still documents 0.2.0 as the version to
set/commit/tag. The release workflow triggers on pushed version-like tags, so tagging the wrong
version can publish the wrong release artifacts.

Cargo.toml[1-6]
RELEASE.md[5-19]
.github/workflows/release.yml[20-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The crate version is now 0.2.1, but `RELEASE.md` still hardcodes `0.2.0` in the example commands. This can lead maintainers to accidentally set/tag the wrong version during the release process.

## Issue Context
The release workflow is tag-driven, so the tag you create/push matters.

## Fix Focus Areas
- RELEASE.md[5-19]
- Cargo.toml[1-6]
- .github/workflows/release.yml[20-46]

## Suggested fix
Update the hardcoded `0.2.0` examples in `RELEASE.md` to `0.2.1`, or (preferably) replace hardcoded versions with a placeholder (e.g. `<version>`) to avoid future staleness.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Release docs version mismatch 🐞 Bug ⚙ Maintainability

After bumping the crate to 0.2.1, RELEASE.md still instructs running cargo set-version 0.2.0 and
tagging v0.2.0, which can lead to cutting/pushing the wrong tag and producing a release that
doesn’t match the code’s declared version.

Agent Prompt

## Issue description
The crate version is now 0.2.1, but `RELEASE.md` still hardcodes `0.2.0` in the example commands. This can lead maintainers to accidentally set/tag the wrong version during the release process.

## Issue Context
The release workflow is tag-driven, so the tag you create/push matters.

## Fix Focus Areas
- RELEASE.md[5-19]
- Cargo.toml[1-6]
- .github/workflows/release.yml[20-46]

## Suggested fix
Update the hardcoded `0.2.0` examples in `RELEASE.md` to `0.2.1`, or (preferably) replace hardcoded versions with a placeholder (e.g. `<version>`) to avoid future staleness.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools