build: semi-automated release process

[extern-c]

Description

Add a release workflow for RubyGems and GitHub Releases triggered by version tags (v*.*.*).

This PR resolves issue: #46.

The workflow consists of three jobs:

1. Test: runs the test suite using Ruby 3.3.
2. RubyGems Release: publishes the gem to RubyGems using trusted publishing.
3. GitHub Release: creates a GitHub Release with generated release notes.

The GitHub Release does not include a built gem package and is intended only for release metadata and assets.

Future Improvements

To keep this change focused, a few related enhancements are left for follow-up work:

• Verify that the gem version matches the release tag before publishing.
• Ensure the tagged commit is reachable from a protected release branch (e.g. main) before publishing to reduce the risk of releasing from an unreviewed commit outside the normal development workflow.
• Generate and publish SHA hashes for release assets.
• Document the release process (e.g. updating the gem version, creating and publishing a release tag, and publishing a release). Updated CONTRIBUTING.md in commit 5545c7c.

Release documentation will be added in a follow-up PR.

Testing

The workflow has been validated to the extent possible, but I was unable to perform an end-to-end test for the RubyGems publishing step because trusted publishing requires maintainer-controlled RubyGems and repository configuration.

A maintainer will need to:

• Create and configure a release environment if one does not already exist.
• Configure RubyGems trusted publishing for the repository/environment.
• Perform a test release to verify that the trusted publishing configuration is set up correctly.

AI Tool Disclosure

• My contribution does not include any AI-generated content
• My contribution includes AI-generated content, as disclosed below:
  • AI Tools: [e.g. GitHub CoPilot, ChatGPT, JetBrains Junie etc.]
  • LLMs and versions: [e.g. GPT-4.1, Claude Haiku 4.5, Gemini 2.5 Pro etc.]
  • Prompts: [Summarize the key prompts or instructions given to the AI tools]

Affirmation

• My code follows the CONTRIBUTING.md guidelines

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[jkowalleck]

the release process looks very promising. 👍

Release documentation will be added in a follow-up PR.

Docs shall happen when changes happen.

Could you please add some docs how this all works and how it is triggered?
This might go here: CONTRIBUTING.md section "To release a new version".
You might want to remove the "Manual process" and add a "Semi-Automated process" or whatever sounds appropriate

please also add a description of the build changes to CHANGELOG.md

[jkowalleck]

please add a comment with the action's URL for easier docks lookup when maintaining.

[extern-c]

Addressed in da61dd3. Thanks for the suggestion.

[jkowalleck]

maybe better go with

Suggested change

	tags: ["v*"]
	tags: ["v*.*.*"]

[extern-c]

Addressed in 3e9e0ba. Thanks for the suggestion.

[Copilot]

Pull request overview

Adds a new GitHub Actions workflow to run tests and perform a semi-automated release flow on version tag pushes, targeting RubyGems (trusted publishing) and GitHub Releases.

Changes:

• Introduces a Release workflow triggered on version tag pushes.
• Adds a test job that runs the rake default task on Ruby 3.3.9 before releasing.
• Adds jobs to publish to RubyGems via trusted publishing and create a GitHub Release with generated notes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jkowalleck]

will review in a week, please ping me if this is ready.
after review, I might trigger a pre-release of this :-)

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[extern-c]

@jkowalleck, do you want to support dot-separated prerelease tags (e.g. v1.2.3.pre.1)?

[jkowalleck]

just go with any standard release system that is used in the ruby world.

[extern-c]

the release process looks very promising. 👍

Release documentation will be added in a follow-up PR.

Docs shall happen when changes happen.

Could you please add some docs how this all works and how it is triggered? This might go here: CONTRIBUTING.md section "To release a new version". You might want to remove the "Manual process" and add a "Semi-Automated process" or whatever sounds appropriate

please also add a description of the build changes to CHANGELOG.md

I've updated CHANGELOG.md and CONTRIBUTING.md in commits e92d1bd and 5545c7c, respectively.

[extern-c]

will review in a week, please ping me if this is ready. after review, I might trigger a pre-release of this :-)

@jkowalleck, this is now ready for review.

[Copilot]

⚠️ Not ready to approve

The workflow’s prerelease classification does not match the documented “supports pre-releases” behavior (and there’s a potential mismatch with the issue requirement about CI tagging releases).

Review details

Comments suppressed due to low confidence (3)

.github/workflows/release.yml:94

• Pre-release detection only handles hyphenated suffixes (e.g. -rc1). Tags like v1.2.3.pre.1 (called out as supported in docs/CHANGELOG) will not be marked as --prerelease on the GitHub Release.

          # Determine release type from tag suffix
          if [[ "$GITHUB_REF_NAME" =~ -(alpha|beta|rc|pre)[0-9.]*$ ]]; then
            FLAGS+=("--prerelease")
          fi

.github/workflows/release.yml:52

• rubygems_release uses a floating Ruby minor (ruby-version: '3.4'), but the main CI workflow pins Ruby patch versions (e.g. .github/workflows/ruby.yml:35-41). Pinning here improves reproducibility and keeps release builds aligned with CI.

          ruby-version: '3.4' # Stable environment to package the gem for the supported ruby versions
          bundler-cache: false

.github/workflows/release.yml:6

• The PR states it resolves #46, whose requirements include "tags releases in git". This workflow is triggered by an existing tag push and does not create/push the tag itself, so it may not fully satisfy that requirement as written.

on:
  push:
    tags: ["v*.*.*"]

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Low

Note

Your feedback helps us improve the quality of this feature.
Please use 👍 or 👎 to tell us whether this assessment is correct.

[extern-c]

⚠️ Not ready to approve

The workflow’s prerelease classification does not match the documented “supports pre-releases” behavior (and there’s a potential mismatch with the issue requirement about CI tagging releases).
Review details

Comments suppressed due to low confidence (3)

.github/workflows/release.yml:94

* Pre-release detection only handles hyphenated suffixes (e.g. `-rc1`). Tags like `v1.2.3.pre.1` (called out as supported in docs/CHANGELOG) will not be marked as `--prerelease` on the GitHub Release.

          # Determine release type from tag suffix
          if [[ "$GITHUB_REF_NAME" =~ -(alpha|beta|rc|pre)[0-9.]*$ ]]; then
            FLAGS+=("--prerelease")
          fi

.github/workflows/release.yml:52

* `rubygems_release` uses a floating Ruby minor (`ruby-version: '3.4'`), but the main CI workflow pins Ruby patch versions (e.g. `.github/workflows/ruby.yml:35-41`). Pinning here improves reproducibility and keeps release builds aligned with CI.

          ruby-version: '3.4' # Stable environment to package the gem for the supported ruby versions
          bundler-cache: false

.github/workflows/release.yml:6

* The PR states it resolves #46, whose requirements include "tags releases in git". This workflow is triggered _by_ an existing tag push and does not create/push the tag itself, so it may not fully satisfy that requirement as written.

on:
  push:
    tags: ["v*.*.*"]

* **Files reviewed:** 3/3 changed files

* **Comments generated:** 1

* **Review effort level:** Low

Note

Your feedback helps us improve the quality of this feature. Please use 👍 or 👎 to tell us whether this assessment is correct.

Tags like 1.2.3.pre.1 are not valid according to SemVer 2.0.0. This project follows SemVer 2.0.0, as stated in the CHANGELOG, where pre-release versions must use a hyphen, e.g, 1.2.3-pre.1, rather than an additional dotted component after the patch version. Please let me know if this should be adjusted. If desired, the SemVer specification provides an official regular expression that could be used for stricter validation.

[jkowalleck]

Tags like 1.2.3.pre.1 are not valid according to SemVer 2.0.0. This project follows SemVer 2.0.0, as stated in the CHANGELOG, where pre-release versions must use a hyphen, e.g, 1.2.3-pre.1, rather than an additional dotted component after the patch version. Please let me know if this should be adjusted. If desired, the SemVer specification provides an official regular expression that could be used for stricter validation.

just go with whatever version schema is used in ruby world.
which seams to be dot-notation ala 1.2.3.pre.1

According to docs

• https://guides.rubygems.org/specification-reference/#version
• https://guides.rubygems.org/patterns/#semantic-versioning
• https://guides.rubygems.org/patterns/#prerelease-gems

this means, ruby is not using Semantic Versioning for pre-releases, but an own dialect.

the pattern *.*.* will still match for this.

Feel free to make this visible in the docs.

[jkowalleck]

this means, ruby is not using Semantic Versioning for pre-releases, but an own dialect.

this is an acknowledged state - see for example https://github.com/package-url/vers-spec/blob/main/docs/types/vers-types.md for "gem"

RubyGems strongly suggests using SemVer for versioning but does not enforce it. As a result some popular packages do not use strict Semver. RubyGems uses their own notation for version ranges which is similar to the "node-semver" notation with some subtle differences.