Composer Changelogs Laravel Package

Product Decisions This Supports

• Release communications and upgrade documentation: composer-changelogs generates a structured, human-readable changelog of dependency changes (added / removed / updated, including version deltas) between two points in a project's history. This directly reduces the manual effort behind customer-facing release notes, internal "what changed" summaries, and upgrade guides for platform/SDK-style products built on PHP.
• Roadmap planning around platform and PHP version support: this release sets the package's floor at PHP 8.1 and validates support up to PHP 8.5. If PHP 8.0 or earlier still appears in your support matrix, this is a forcing function to schedule that deprecation — or to pin the tool at v2.1.x.
• Build vs. buy for changelog tooling: the alternative is a bespoke script or manual release-note discipline. This package is small, Composer-native, and dev-only, which makes "buy" (adopt) the low-effort default unless you have bespoke formatting or multi-language (npm/JS, Python) needs.
• Audit and traceability hygiene: a per-release dependency diff is a lightweight, reviewable record of third-party change — useful for security reviews, client/agency handover reports, and answering "when did this transitive dependency move?" without reconstructing it later.
• Reducing release-engineering toil: as a PM, this is the kind of decision that buys back engineering time on every release, which matters most for teams shipping frequently or maintaining multiple version streams.

When to Consider This Package

Adopt when:

• Your stack is PHP with Composer, and you ship versioned releases (libraries, SDKs, platform releases, client deliverables).
• Your release process already lives near CI; the tool fits naturally into a release job to produce notes as an artifact.
• You want dependency-level change history that a non-author (support, sales engineering, a client) can read.
• You need a low-risk, dev-dependency-only addition — it does not ship to production runtime.

Look elsewhere or defer when:

• Your primary ecosystem is JavaScript/TypeScript, Python, or Go — pair this with ecosystem-specific tooling (e.g. Changesets for npm) rather than forcing a PHP tool into a non-PHP pipeline.
• What you actually need is vulnerability and licence analysis — that is composer audit, Dependabot/Renovate, or a commercial SCA product. This tool describes what changed, not what is risky.
• You are below PHP 8.1. v2.2.0 is a hard break for PHP 8.0 and earlier; stay on v2.1.0 until the platform upgrade lands, and treat that pin as a tracked risk with an owner and a date.
• You require vendor support, SLAs, or a maintained UI/dashboard; this is community-maintained CLI tooling.
• You are on a monorepo or a heavily vendored build where "composer.json changed" is not a meaningful release unit.

How to Pitch It (Stakeholders)

For executives: this is a small, dev-only utility that automates the "what changed in this release" write-up we currently produce by hand. The cost is negligible and the payoff is recurring: every release gets consistent, accurate change notes, and we get a durable record of third-party dependency movement for audit conversations. It never runs in production and adds no customer-facing risk.

For engineering: adopting it means less time reconstructing dependency diffs at release time. Note the v2.2.0 constraint — PHP 8.1 minimum, tested through PHP 8.5 — which aligns with where the platform should be heading anyway; teams still on 8.0 pin to v2.1.0. Integration is a release-pipeline step, not application code.

The ask: approve it as a dev dependency, and confirm the PHP 8.1 baseline is consistent with the platform upgrade roadmap. If it isn't, we hold at v2.1.0 and revisit alongside that upgrade rather than adopting now.