Skip to content

ci(release): release on every merge to main with semantic-release - #2

Merged
onamfc merged 1 commit into
mainfrom
ci/semantic-release
Oct 17, 2026
Merged

onamfc merged 1 commit into
mainfrom
ci/semantic-release

Conversation

@onamfc

@onamfc onamfc commented Oct 17, 2026

Copy link
Copy Markdown
Member

Description

Every merge to main now releases when its commits call for one, the same way LinkForty Core does.

  • .github/workflows/release.yml runs on push to main instead of on a tag. It lints, runs phpcs, then npx semantic-release.
  • .releaserc.json uses Core's rules: feat → minor; fix / docs / refactor / perf / revert → patch; chore / test / ci / build → none. One difference: a breaking change bumps the minor version while the plugin is below 1.0 (semver allows this for 0.x). At 1.0, change that rule to major.
  • On a release:
    1. scripts/set-version.sh writes the version into the plugin header, the LINKFORTY_VERSION constant and readme.txt's Stable tag. It exits non-zero if any of the three doesn't match.
    2. @semantic-release/changelog prepends the release notes to CHANGELOG.md.
    3. composer build makes linkforty-x.y.z.zip.
    4. @semantic-release/git commits chore(release): x.y.z [skip ci].
    5. @semantic-release/github tags vx.y.z and publishes the release with the zip attached.
  • package.json is private and holds the release tooling only. It, package-lock.json, .releaserc.json and scripts/ are added to .distignore, so the zip is unchanged (checked with composer build).
  • CONTRIBUTING.md and the PR template now say:
    • PRs are squash-merged, so the PR title becomes the release commit and its changelog line.
    • A breaking change needs ! and a BREAKING CHANGE: note.
    • Nobody edits CHANGELOG.md or the version by hand.

Catching up 0.2.0

PR #1 (purchase revenue, begin_checkout → cart_total) was merged without a release, and its commit isn't conventional, so semantic-release wouldn't release it. This PR sets 0.2.0 by hand: the header, the constant, Stable tag, and ## [0.2.0] in the changelog. After merging, tag the merge commit v0.2.0 and publish that release once by hand. semantic-release then counts from v0.2.0.

Use a squash merge so the title above is the commit on main. It's a ci: commit, so the release job runs and correctly releases nothing.

Type of change

  • Refactor or tooling

Testing

  • scripts/set-version.sh 9.8.7 writes all three places; scripts/set-version.sh nope exits 1
  • npx semantic-release --dry-run on this branch finds v0.1.0, analyzes the 4 commits since it, and reports no release (none are feat/fix), as expected
  • composer build zip contains only the plugin files
  • composer lint and composer phpcs pass; the CI header check passes at 0.2.0

Checklist

  • The title is a conventional commit
  • README and readme.txt unchanged (no setting, event or hook changed)

Pushes to main run semantic-release (.releaserc.json, same rules as
LinkForty Core). When the conventional commits since the last tag warrant
a release, it writes the version into linkforty.php and readme.txt
(scripts/set-version.sh), prepends CHANGELOG.md, builds the zip, commits
`chore(release): x.y.z [skip ci]`, tags vx.y.z and publishes a GitHub
release with the zip attached. Below 1.0 a breaking change bumps the minor
version.

This also sets 0.2.0 for the purchase-revenue fix already on main, which
landed without a release; v0.2.0 is tagged on this merge so semantic-release
starts from it. CONTRIBUTING.md and the pull request template now say the
PR title is the release commit and that nobody edits the changelog or the
version by hand.
@onamfc
onamfc merged commit d3a1c4e into main Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant