feat: add release automation command /release with version bump and CHANGELOG update logic#1204
feat: add release automation command /release with version bump and CHANGELOG update logic#1204
/release with version bump and CHANGELOG update logic#1204Conversation
… CHANGELOG update logic
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
||
| 5. Commit `CHANGELOG.md` with message: `docs: update CHANGELOG for NEW_VERSION release` | ||
|
|
||
| After completing all steps, show the user a summary of what was done. If PRs were found, list them. If the placeholder `-` was used instead, remind them to fill in the `### What's Changed` bullet points in `CHANGELOG.md` before merging. |
There was a problem hiding this comment.
Can you add one more step, to validate changes made in accordance with original requirement and fix them if anything missing found
| 7. Create the release and the release tag on Github including populating the release notes | ||
| 8. Use the [GitHub action](https://github.com/ably/ably-java/actions/workflows/release.yaml) to publish the release. Run the workflow on the latest release tag. | ||
| 9. Create the entry on the [Ably Changelog](https://changelog.ably.com/) (via [headwayapp](https://headwayapp.co/)) | ||
| 1. Run `/release patch|minor|major` in Claude Code — this creates the release branch, bumps the version in all required files, and populates the [CHANGELOG](./CHANGELOG.md) with merged PRs since the last tag automatically |
There was a problem hiding this comment.
I wouldn't recommend having claude dependent release process, since it frequently goes down and can delay the release. Maybe you should create a separate section
### Release using LLM
Add relevant steps there. maybe, sometime in near future, if claude gets replaced by other LLM, the release docs will still be relevant ( both manual and automated )
| Then perform these steps in order: | ||
|
|
||
| 1. Run `git checkout -b release/NEW_VERSION` | ||
| 2. Replace `OLD_VERSION` with `NEW_VERSION` in all of the following files: |
There was a problem hiding this comment.
maybe apply regex here to change all versions in all files excluding CHANGELOG.md.
So, we don't need to manually specify each file.
There was a problem hiding this comment.
I afraid if we ask him to use regexp we can accidentally bump libraries that we shouldn't simply because they have the same version as ably-java. I want to be extremely caution here
There was a problem hiding this comment.
Maybe add some exceptions, then regex should work fine wdyt
There was a problem hiding this comment.
Pull request overview
Adds documentation and a Claude Code command definition to automate the release workflow (create release branch, bump version references, and prepend a new CHANGELOG entry from merged PRs).
Changes:
- Replaces the manual release steps in
CONTRIBUTING.mdwith a/release patch|minor|majorworkflow. - Adds a new Claude Code command spec at
.claude/commands/release.mddescribing the automated steps (version bump + CHANGELOG update).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
CONTRIBUTING.md |
Updates the documented release process to use /release automation. |
.claude/commands/release.md |
Defines the /release command procedure for version bumping and CHANGELOG population. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 2. Review the `### What's Changed` entries in [CHANGELOG.md](./CHANGELOG.md) and adjust if needed, then commit any edits | ||
| 3. Make a PR against `main` | ||
| 4. Once the PR is approved, merge it into `main` | ||
| 5. Create the release and the release tag on Github including populating the release notes |
There was a problem hiding this comment.
Line uses "Github"; repository/docs elsewhere use the correct capitalization "GitHub". Please update for consistency (e.g., "Create the release and the release tag on GitHub …").
| 5. Create the release and the release tag on Github including populating the release notes | |
| 5. Create the release and the release tag on GitHub including populating the release notes |
| - `README.md` — 3 places: Maven `<version>`, Gradle `implementation '…'`, and LiveObjects `runtimeOnly("…")` | ||
| - `CONTRIBUTING.md` — the `implementation files('libs/ably-android-OLD_VERSION.aar')` line | ||
| - `lib/src/test/java/io/ably/lib/test/realtime/RealtimeHttpHeaderTest.java` — the hardcoded `"ably-java/OLD_VERSION"` string in the agent header assertion | ||
| Commit all five files together with message: `chore: bump version to NEW_VERSION` |
There was a problem hiding this comment.
The step lists 4 files to update (gradle.properties, README.md, CONTRIBUTING.md, RealtimeHttpHeaderTest.java) but then says "Commit all five files together". Please reconcile the count (either list the missing file or change to four).
| Commit all five files together with message: `chore: bump version to NEW_VERSION` | |
| Commit all four files together with message: `chore: bump version to NEW_VERSION` |
| 3. Fetch merged PRs since the last release tag using: | ||
| ``` | ||
| gh pr list --state merged --base main --json number,title,mergedAt --limit 200 | ||
| ``` | ||
| Then get the date of the last release tag with: | ||
| ``` | ||
| git log vOLD_VERSION --format="%aI" -1 | ||
| ``` | ||
| Filter the PRs to only those merged after that tag date. Format each as: | ||
| ``` | ||
| - Short, one sentence summary from PR title and description [#NUMBER](https://github.com/ably/ably-java/pull/NUMBER) | ||
| ``` |
There was a problem hiding this comment.
Step 3 says to write a summary from the PR title and description, but the suggested gh pr list command only fetches number,title,mergedAt so the description/body isn't available. Either include body in the JSON fields (and/or switch to gh pr view per PR) or update the instruction to use only the title.
| Then get the date of the last release tag with: | ||
| ``` | ||
| git log vOLD_VERSION --format="%aI" -1 | ||
| ``` | ||
| Filter the PRs to only those merged after that tag date. Format each as: | ||
| ``` | ||
| - Short, one sentence summary from PR title and description [#NUMBER](https://github.com/ably/ably-java/pull/NUMBER) | ||
| ``` | ||
| If the tag doesn't exist or there are no merged PRs, use a single `-` placeholder bullet instead. |
There was a problem hiding this comment.
The instructions mention handling the case where tag vOLD_VERSION doesn't exist, but step 3 unconditionally runs git log vOLD_VERSION ..., which will error in that scenario. Add an explicit check/fallback (e.g., detect missing tag and skip date filtering / use the latest tag) so the command remains usable.
| Then get the date of the last release tag with: | |
| ``` | |
| git log vOLD_VERSION --format="%aI" -1 | |
| ``` | |
| Filter the PRs to only those merged after that tag date. Format each as: | |
| ``` | |
| - Short, one sentence summary from PR title and description [#NUMBER](https://github.com/ably/ably-java/pull/NUMBER) | |
| ``` | |
| If the tag doesn't exist or there are no merged PRs, use a single `-` placeholder bullet instead. | |
| Then get the date of the last release tag, only if the tag exists: | |
| ```bash | |
| if git rev-parse -q --verify "vOLD_VERSION^{tag}" >/dev/null; then | |
| git log vOLD_VERSION --format="%aI" -1 | |
| else | |
| # Tag doesn't exist; skip date filtering and consider all fetched PRs as candidates. | |
| echo "" | |
| fi |
If a tag date is available, filter the PRs to only those merged after that tag date. If no tag date is available (because the tag doesn't exist), either:
- treat all fetched PRs as candidates, or
- if there are no relevant PRs to include, fall back to the placeholder below.
Format each included PR as:
- Short, one sentence summary from PR title and description [#NUMBER](https://github.com/ably/ably-java/pull/NUMBER)
If, after applying this logic, there are no PRs to list, use a single - placeholder bullet instead.
Release automation command
/releasewith version bump and CHANGELOG update logic