Skip to content

Latest commit

 

History

History
79 lines (55 loc) · 2.69 KB

File metadata and controls

79 lines (55 loc) · 2.69 KB

Release process

This document describes how to prepare and publish a new release of Sentry Bundle.

Table of contents

Pre-release checks

Run the full release check (style, static analysis, tests, demos):

make release-check

This runs:

  • ensure-up – Docker PHP service up and dependencies installed
  • composer-sync – validate composer.json and align composer.lock (--no-install)
  • cs-fix and cs-check – code style
  • rector-dry – Rector in dry-run
  • phpstan – static analysis (phpstan.neon.dist)
  • coverage-check – full test-coverage flow (console coverage + coverage-php.txt + global Lines % script) and Clover threshold check (95%)
  • release-check-demos – runs make -C demo release-check (demo update-bundle-alltest-coverage-allrelease-verify per demo)

Fix any failure before tagging.

Versioning

We follow Semantic Versioning:

  • MAJOR – incompatible API changes
  • MINOR – new backward-compatible functionality
  • PATCH – backward-compatible bug fixes

Releasing

  1. Update docs/CHANGELOG.md: add a new ## [X.Y.Z] - YYYY-MM-DD section with the changes and move them from [Unreleased] (see Keep a Changelog).
  2. Update docs/UPGRADING.md if the new version has upgrade notes (release date, breaking changes, new config).
  3. Commit: git add docs/CHANGELOG.md docs/UPGRADING.md && git commit -m "Prepare release X.Y.Z".
  4. Create an annotated tag:
    git tag -a vX.Y.Z -m "Release vX.Y.Z"
    git push origin vX.Y.Z
  5. GitHub Actions will create the GitHub Release from the tag and attach the changelog entry for that version.

After release

  • Verify the release on Packagist and that the Flex recipe (if used) applies correctly.
  • Optionally announce in your usual channels.

Example: releasing 1.9.1

After CHANGELOG and UPGRADING are updated and committed:

# 1. Run pre-release checks
make release-check

# 2. Commit release docs (if not already committed)
git add docs/CHANGELOG.md docs/UPGRADING.md docs/RELEASE.md
git commit -m "docs: prepare release 1.9.1"

# 3. Create and push tag (triggers GitHub Release via Actions)
git tag -a v1.9.1 -m "Release v1.9.1"
git push origin main
git push origin v1.9.1

(Adjust main if your default branch is master.)

After creating the release commit and tag, run make check-no-cursor-coauthor again before git push (REQ-GIT-001). The release commit itself is not covered by an earlier release-check run.