Statamic Changelog Laravel Package

Technical Evaluation

Architecture fit — This is a Statamic 6 addon, not a general-purpose Laravel package. It runs in-process inside the control panel and acts as a read-only consumer of git log, rendering results in the CP nav and a changelog view. It does not touch content models, collections, or the content repository, and the only persistent state is a per-user "last seen" marker. Architecturally it is a thin presentation-layer addon with a very small surface area — which is a point in its favor.

Integration feasibility — Install is a single composer require with auto-discovery; the icon appears in the nav with no configuration. The happy path is genuinely zero-config. The actual feasibility gate is not the package but the runtime environment: the PHP process needs a git binary on PATH and a readable .git directory co-located with the app. That precondition is where most organizations will either sail through or fail outright.

Technical risk

• Deploy artifacts: containerized or immutable deploys routinely exclude .git from the build context. Serverless targets (Laravel Vapor) have neither git nor a repository at all. In those environments the feature is not degraded — it is non-functional.
• Shallow clones: CI pipelines using --depth=1 will produce a one-commit changelog that looks authoritative but is silently wrong. This is the most dangerous failure because it does not error.
• Git safety checks: .git ownership mismatches (common when files are copied in a build step) trigger git's "dubious ownership" refusal unless safe.directory is configured.
• Disabled functions: hardened PHP hosts that block exec/proc_open will break it.
• CP latency: an unseen badge in the top nav implies a git invocation on or near every CP page load. Without caching this is a real performance concern on large repositories.
• Information disclosure: commit messages and author identities become visible to every CP user. Release notes do not mention permission gating, and commit messages frequently contain internal ticket IDs, URLs, or worse.
• Supply chain: v1.0.0, single-maintainer package, no mention of license, test suite, or support policy.
• Mitigating factor: the package is read-only and has no content-mutation path, so the blast radius of a failure is a broken badge, not corrupted data.

Key questions

• Is the changelog permission-gated, and can it be restricted to specific roles/groups?
• Is the git log read cached, and does the nav badge trigger a git call on every CP request?
• Where is per-user "last seen" state persisted — user meta or a custom table — and is it cleaned up on uninstall?
• What is the behavior when git is missing or .git is absent: silent empty state, exception, or broken CP nav?
• How are shallow clones and force-pushes/rebases handled with respect to the unseen count?
• Can it target a repository other than the app root (split content/code repos)?
• What license, support commitment, and Statamic 6 compatibility policy apply?

Integration Approach

Stack fit — Applies only if the organization is actually on Statamic 6 with PHP 8.3+. Teams on Statamic 4/5 or PHP 8.1/8.2 cannot use it without a platform upgrade, which is a far larger project than the value of a changelog badge justifies. For plain Laravel applications this package is simply not applicable.

Migration path — None required. There is no data migration; installation is purely additive, and rollback is composer remove with only inert per-user timestamp state left behind. This is about as reversible as a dependency gets.

Compatibility — Pin the version explicitly. Statamic 6 is a young major, so expect addon releases to track core point releases; pinning avoids surprise breakage during a core upgrade. Verify behavior with Statamic's own Git addon both enabled and disabled, since the "hide auto-commits" toggle is a headline feature and its filtering should be confirmed against real Spock/Content saved output.

Sequencing

1. Confirm PHP 8.3+ and Statamic 6 across all target environments — this is a hard gate, not a preference.
2. Audit the deploy pipeline for .git presence and clone depth before piloting. If production artifacts exclude .git, stop here rather than discovering it post-rollout.
3. Pilot in staging against a full clone with a production-sized history; measure CP nav latency with the badge active.
4. Settle the permission model with security/ops before any production exposure.
5. Roll out to a single CP user group, observe for a release cycle, then widen.

Operational Impact

Maintenance — Code maintenance is minimal, but you are taking on a composer dependency on a single-maintainer addon and an implicit runtime contract with your deployment tooling. Budget a re-verification step at every Statamic major upgrade and after any change to the build pipeline.

Support — End-user support load is essentially zero; the badge appears and behaves. Operational support is where the cost sits: any pipeline change that drops the .git directory silently disables the feature, and the failure presents as "the changelog is empty" rather than an error. Document the git-and-repo dependency in the runbook so it is not rediscovered during an incident.

Scaling — Scales with the number of CP users (negligible state) rather than with content volume. The real scaling dimension is repository history: git log cost grows with commit count and repo size. Mitigate with the configurable commit limit, path filters, and merge-commit exclusion. Large monorepos are the worst case and should be benchmarked during the pilot.

Failure modes — Missing git binary; absent or shallow .git; ownership/safe.directory rejection; disabled exec functions; commit metadata leaking to unauthorized CP users; stale or inflated unseen counts after a rebase or force-push; CP navigation latency on large histories.

Ramp-up — Near-zero for editors and marketers — the feature is self-explanatory and requires no training. Roughly half a day for the implementing developer, plus a short ops verification of the deploy pipeline. Overall this is a cheap, low-risk, easily reversible win if the infrastructure preconditions hold; if the environment cannot expose .git to the runtime, the effort is better spent elsewhere.