Draft Release

First, let's work on the following steps.

1. Confirm that you are currently on the main branch and pull the latest changes. If not on the main branch, switch to it.
2. Compare code changes between the previous version tag and the latest commit to prepare the release description.

• Write in English.
• Do not include confidential information.
• Sections What's Changed, Contributors and Full Changelog are needed.
• ./tmp/release-notes/*.md will be used as the release notes.

Then, get the requested new version from the user's request without the v prefix and assign it to $new_version. For example, if the request specifies "v1.0.0", the new version is "1.0.0".

If the user does not specify a version, determine it automatically by analyzing the diff and applying semantic-versioning rules: a breaking change bumps the major, a new feature bumps the minor, and a bug fix bumps the patch.

Let's resume the release process.

3. Run git pull.
4. Run git checkout -b release/v${new_version}.
5. Bump the version in package.json to ${new_version} with pnpm version ${new_version} --no-git-tag-version (or edit the version field directly). The CLI reads its version from package.json, so no other file needs to change.
6. Run pnpm run cicheck. If the checks fail, fix the code until they pass.
7. Execute git add, git commit and git push.
8. As a precaution, verify that ghactivities --version (or pnpm dev --version) reports ${new_version}.
9. Run gh pr create targeting the main branch.
10. Create a draft release with gh release create v${new_version} --draft --title v${new_version} --notes-file ./tmp/release-notes/*.md on the github.com/dyoshikawa/ghactivities repository. Creating a draft (instead of publishing) lets you review it before the release workflow publishes to npm.