Skip to content

RELEASING.md

Latest commit

 

History

History
40 lines (31 loc) · 1.98 KB

RELEASING.md

File metadata and controls

40 lines (31 loc) · 1.98 KB
Raw

Releasing patches

Publishing is only ever done by GitHub Actions (.github/workflows/release.yml), triggered by a vX.Y.Z tag whose commit is reachable from develop. Tags on any other branch are rejected by the workflow before anything is built. No one needs local publishing credentials — the workflow authenticates to RubyGems.org via OIDC trusted publishing.

The v prefix is required: the workflow triggers on v*, and it is the tag rake release creates. RubyGems.org strips it, so v3.6.3 publishes version 3.6.3 — which is why the versions listed on rubygems.org never carry the prefix.

Cutting a release

  1. Bump MAJOR / MINOR / PATCH in lib/patches/version.rb.

  2. Replace unreleased in the ## [X.Y.Z] - unreleased heading at the top of CHANGELOG.md with today's date. A release branch carries unreleased while it waits for review, so the date is always the day it ships - 3.7.0 shipped a week after its entry was drafted and claimed the drafting date until someone noticed.

  3. Commit both changes and get them onto develop (PR + merge, as normal).

  4. From an up-to-date develop, tag the commit and push the tag:

    git tag vX.Y.Z
git push origin vX.Y.Z

  5. Watch the "Release" workflow run in the Actions tab.

  6. Confirm the new version shows up on rubygems.org.

Do not run bundle exec rake release from a workstation. It would push the gem under your own credentials and push the tag, and the workflow's own rake release would then fail because the version already exists.

One-time setup

  • RubyGems.org: an existing owner of the patches gem must add a Trusted Publisher for rdytech/patches, workflow release.yml (no environment). See Trusted Publishing: adding a publisher. Until this is done, the release will fail while configuring credentials. The gem currently lists a single owner, handle jr.