Rmt Laravel Package

Getting Started

Start by installing RMT as a dev dependency (composer require --dev liip/rmt), then initialize with php vendor/liip/rmt/command.php init — this generates .rmt.yml and a ./RMT executable. Run ./RMT to see available commands; the most common workflow begins with ./RMT release. The default interactive release sequence validates prerequisites, prompts for version type (e.g., major, minor, patch if using semantic versioning), executes pre-release hooks, commits the new version, tags it, and runs post-release steps. First-time users should pick a configuration example from the README (e.g., Git + changelog + semantic versioning) and adapt it to match their release process.

Implementation Patterns

• Branch-specific workflows: Define _default config and branch overrides (e.g., main branch enforces changelog updates, develop skips tagging). Use ./RMT config to verify merged configuration.
• Semantic versioning + Git tags: Use version-generator: semantic, version-persister: vcs-tag, and optionally set tag-prefix: "{branch-name}_" for per-branch tag isolation. Combine with changelog-update (format: markdown) and vcs-commit/vcs-publish actions.
• CI/CD integration: For automated releases (e.g., on main merges), run ./RMT release minor --no-interaction (or patch) with CI-provided credentials and GPG signing (sign-tag: true). Prepend with working-copy-check + tests-check as prerequisites.
• Multi-file version persistence: Use files-update to simultaneously update version in src/Version.php, package.json, and docker-compose.yml by listing multiple file configs. Prefer files-update over deprecated update-version-class.
• Custom steps: Extend via PHP scripts (e.g., bin/MyVersionGenerator.php) and reference in .rmt.yml under version-generator or action hooks.

Gotchas and Tips

• Config merge quirks: Branch overrides only apply when the current branch name matches a top-level key exactly—branch names like feature/x_y won’t match unless defined literally. Use ./RMT config to debug merging.
• Prerequisite interactivity: Actions like composer-stability-check or tests-check are non-interactive by default in CI (--no-interaction), but working-copy-check requires flags like --ignore-check to bypass—even then, it may fail silently if allow-ignore isn’t set.
• Version pattern pitfalls: When using vcs-tag persister, ensure tag-pattern regex includes the branch placeholder if used—misconfigured patterns cause tag collisions (e.g., v1.0.0 from main vs develop).
• Command variables: pre/post-release command actions support %version% and %new_version%, but these are resolved after version generation—ensure commands run after persister steps if version-dependent.
• Phar caveats: The build-phar-package action’s excluded-paths regex must be PCRE-compatible and escaped properly; malformed regexes break the build without clear errors.
• Git signing: For sign-tag: true to work, ensure GPG is configured and gpg is in $PATH; otherwise, vcs-tag silently falls back to unsigned tags. Check git log --show-signature post-release.
• Deprecation alert: update-version-class is deprecated—migrate to files-update with explicit pattern: 'const VERSION = '\''%version%'\'';' to avoid accidental replacements.