Crap Metric Analyzer Laravel Package

Product Decisions This Supports

• CI/CD and quality-gate investment: v1.0.4 keeps the package aligned with the newest Clover coverage report structure, so coverage parsing/consumption keeps working after toolchain upgrades. This directly supports decisions about whether coverage thresholds can be enforced automatically in CI rather than tracked manually.
• Build vs. buy for test-observability plumbing: coverage-report parsing is undifferentiated glue work. This release is evidence the maintainer is actively tracking upstream format changes, which strengthens the case for buying/adopting rather than building an in-house parser.
• Dependency and upgrade policy: the stated maintenance stance — "support always only the newest structure" — is a product constraint, not just an implementation detail. It should shape the roadmap for PHPUnit/PHP version upgrades and the decision to pin this package to a known-good version.
• Roadmap sequencing for developer-experience work: if coverage reporting is on the roadmap (PR coverage annotations, dashboards, merge/multi-suite coverage), this release removes a likely blocker and lets that work proceed without a bespoke compatibility layer.
• Risk register entry: the explicit drop of older Clover structures is a forward-looking compatibility bet. PMs should record it as a known constraint affecting any team still on an older PHPUnit/toolchain.

When to Consider This Package

Consider adoption when:

• Your pipeline emits Clover-format coverage and you need it parsed, merged, or surfaced (PR annotations, dashboards, threshold checks).
• Your team tracks, or is willing to track, the newest PHPUnit/coverage tooling; the maintainer's policy of supporting only the newest structure means you stay current by design.
• You want a small, single-purpose dependency rather than maintaining a parser in-house.
• You can absorb periodic minor upgrades as part of routine dependency maintenance (this is a v1.0.4 patch, so the change is presented as compatibility, not a breaking API shift).

Look elsewhere when:

• You are pinned to an older PHPUnit or Clover schema for compliance, long-term-support, or platform reasons. The maintainer has stated older structures will not be supported, so you would be relying on an unsupported path.
• You need multi-format coverage ingestion (Cobertura, OpenCover, LCOV) from one tool.
• You require a formal deprecation/LTS policy with advance notice windows; "newest only" is a reasonable but strict stance that may not fit enterprise change-control.
• Evidence is thin: this assessment is based solely on the v1.0.4 release notes. Before committing, confirm actual format coverage, API stability, test coverage of the package itself, and issue-tracker responsiveness.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk maintenance release for a small piece of our test-reporting plumbing. It keeps coverage reporting working as we upgrade our PHP testing toolchain, which protects the automated quality gates we rely on for release confidence. No new spend, no new vendor relationship, no migration project. The one thing to note is a deliberate policy choice by the maintainer: they will only support the newest coverage-report format. That is good for staying current and bad for anyone frozen on old tooling, so it belongs in our dependency-review checklist rather than in a budget conversation.

For engineering: v1.0.4 adds support for the newest Clover coverage report structure. The maintainer has explicitly stated an "newest structure only" support policy for maintenance simplicity, which means we should (a) pin the version in composer and upgrade deliberately alongside PHPUnit, (b) verify our CI's Clover output matches the newly supported schema before rollout, and (c) treat future Clover schema changes as expected upgrade events rather than surprises. Because there is no prior assessment on record and the upstream dataset is empty, treat this as an initial, evidence-limited evaluation — validate format handling and package test coverage against our own pipeline in a branch before promoting past dev/CI.