Composer Changelogs Laravel Package

Product Decisions This Supports

• Release communications as an automated capability, not a chore. This package hooks into Composer to generate changelogs and release notes from VCS history and dependency changes. The decision it informs is whether release documentation stays a manual, error-prone step or becomes a deterministic artifact of the build.
• Build vs. buy vs. script-it-yourself. It is a narrow, single-purpose Composer plugin. The realistic comparison is against a homegrown git-log parser or a heavyweight release-orchestration SaaS — this sits in the cheap, low-lock-in middle.
• Standardizing release cadence. Once changelog generation is reliable, teams can shorten release cycles without proportional increases in communication overhead. This is the lever for moving from quarterly drops to frequent releases.
• Audience-specific release messaging. Template-driven output (Mustache) means one source of truth can produce an engineering-facing changelog and a customer- or stakeholder-facing summary. That supports decisions about how much detail to expose externally.
• Upgrade and dependency transparency. Surfacing dependency changes in generated notes supports decisions about upgrade timing, deprecation communication, and support-ticket deflection.
• Compliance and audit trail. A generated, consistent record of what shipped when reduces manual effort in post-incident review and audit preparation.

Release 2.0.0 impact on these decisions: the headline is operational, not functional. Dropping Composer 1 is a breaking change that gates adoption for any team still on legacy Composer — verify build agents and developer machines before committing. In exchange, the package now supports Symfony 8 in a backwards-compatible way down to PHP 7.1, and re-allows PHP 7.1–7.3. That materially widens the addressable footprint: teams on older PHP runtimes and teams planning a Symfony 8 upgrade no longer need to exclude this from their roadmap. The loosened mustache/mustache constraint reduces future dependency-conflict friction, which lowers the long-term maintenance cost estimate. No feature regressions or deprecations were introduced.

When to Consider This Package

Adopt when:

• Your release process is Composer-centric (PHP/Laravel services or libraries) and changelogs are currently written by hand or skipped.
• You already practice reasonable commit hygiene, or are willing to — the output quality is bounded by input quality.
• You want changelog generation to run inside CI with no external service, credentials, or vendor dependency.
• You need multiple output formats for different audiences and are comfortable maintaining Mustache templates.
• Your fleet spans mixed PHP versions (7.1 through 8.5 per the current CI matrix) or you are planning a Symfony 8 migration.
• You want a low-commitment trial: it is a dev/build-time tool, not a runtime dependency, so reversal cost is low.

Look elsewhere when:

• You are still on Composer 1. 2.0.0 drops it outright, and the maintainers explicitly cannot guarantee future compatibility. This is a hard blocker — do not plan adoption until the Composer 2 migration is complete.
• Your release surface is not Composer-based (npm, Maven, container-only deploys) — the plugin will not see your releases.
• You want hosted release management with dashboards, approvals, and analytics; this is a CLI-side generator, not a platform.
• You require conventional-commit parsing with strict semantic-version inference — validate fit against the actual parsing behavior before committing.
• You need vendor support or an SLA; this is a community package with a small maintainer base.
• You are on PHP below 7.1.

Assessment of 2.0.0 for adoption criteria: the Composer 1 removal tightens the gating criteria but does not narrow the practical audience, since Packagist no longer functions with Composer 1. The PHP 7.1–7.3 reinstatement and Symfony 8 readiness loosen the criteria and remove two prior reasons to defer. Net: the adoption recommendation is unchanged in direction but broader in reach — add "Composer 2 required" as an explicit pre-flight checklist item.

How to Pitch It (Stakeholders)

For executives: Release notes are consistently the first thing to slip when delivery pressure rises, and inconsistent release communication shows up as support load and customer confusion. This package automates changelog and release-note generation from work we are already doing, inside our existing build pipeline. It is a development-time tool with no runtime footprint, no vendor contract, and negligible cost — the exposure is measured in engineer-hours, not budget. The 2.0.0 release confirms the package is actively maintained: it is current with Symfony 8, supports PHP 7.1 through 8.5, and has a CI matrix that actually exercises those versions. The one hard requirement is that we be on Composer 2 — which we should be regardless, since Composer 1 is no longer served by Packagist.

For engineering: A Composer plugin that generates changelogs and release notes from VCS history and dependency changes, with Mustache templates for output formatting. It is a build/dev dependency only. 2.0.0 drops Composer 1 — confirm CI images and local toolchains are on Composer 2 before rollout. It adds Symfony 8 compatibility while remaining backwards compatible to PHP 7.1, re-enables PHP 7.1–7.3, and relaxes the mustache/mustache constraint to reduce conflict risk. Dev-dependency hygiene was cleaned up (abandoned sebastian/phpcpd and unused PHPUnit removed), and the 7.1–8.5 CI matrix means the supported-version claim is verified rather than asserted. Expect the usual trade-off for this class of tool: output quality tracks commit-message discipline, and the templates are ours to own. Recommended path is a time-boxed trial on one or two repositories, with a go/no-go based on how much manual release-note editing disappears.