Skip to content

RELEASE.md

Latest commit

 

History

History
38 lines (28 loc) · 1.62 KB

RELEASE.md

File metadata and controls

38 lines (28 loc) · 1.62 KB
Raw

Release process

Creating a new version (e.g. v1.0.14)

  1. Ensure everything is ready

    • CHANGELOG.md has the target version (e.g. [1.0.14]) with date and full entry; [Unreleased] is at the top and empty or updated for the next cycle.
    • UPGRADING.md has a section "Upgrading to X.Y.Z" with what's new, breaking changes (if any), and upgrade steps.
    • Tests pass: make test or composer test.
    • Code style: make cs-check or composer cs-check.

  2. Commit and push any last changes to your default branch (e.g. main or master):

    git add -A
git commit -m "Prepare v1.0.14 release"
git push origin HEAD

  3. Create and push the tag

    git tag -a v1.0.14 -m "Release 1.0.14
  • Makefile: release-check target (cs-fix, cs-check, test-coverage, demo healthchecks)
  • Demo Makefiles: release-verify, restart, build targets; help text updated
  • PHP CS Fixer fixes [skip ci]
  • Docs: RELEASE.md, SECURITY.md" git push origin v1.0.14

  1. GitHub Actions (if configured) may create the GitHub Release from the tag.

  2. Packagist (if the package is registered) will pick up the new tag; users can then composer require nowo-tech/anonymize-bundle.

After releasing

  • Keep ## [Unreleased] at the top of CHANGELOG.md for the next version; add new changes there.
  • Optionally bump a dev version in composer.json for development.

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.