Commit History Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the changelog surface. Replaces a hand-maintained CHANGELOG.md plus a bespoke admin page with a config-driven commit timeline. Weeks of UI plumbing (import, storage, list/timeline rendering) collapse into a bundle install, one config file, and a console command in the deploy pipeline.
• Whether release communication is a retention lever. The same imported data set can power a public /changelog page and an in-app "What's new" panel with unread tracking. That reframes an obvious ops-tooling decision into a product-loop decision: is announcing shipped features worth the surface area?
• Support and incident-triage efficiency. Mapping deployed version → commits makes "what changed and when did it change" answerable in seconds during an escalation. This is a concrete, measurable support-cost reduction that usually justifies the dependency on its own.
• Trust and transparency positioning. A live changelog is a lightweight trust artifact for customers and prospects. The PM decision is editorial: raw commit messages (fast, honest, occasionally embarrassing) versus tag-grouped, curated release entries (better polish, needs a lightweight curation pass).
• Stack-scoping and portfolio consistency. This is a Symfony bundle, not Laravel: it ships a Bundle class, DI configuration, a Doctrine entity, a console command, and Twig templates. For a Laravel product the decision reframes to "reimplement the git-log importer as an artisan command" or stand up a small Symfony sidecar. Worth knowing before it appears in a sprint plan and gets scoped as a drop-in.
• Adjacent decisions this forces into the open — schedule them, don't discover them: whether commit messages are user-facing (raises git-hygiene standards), whether the page is public or admin-gated, import frequency and who owns it, and whether to invest in curated release notes downstream.
• Scope caveat to hold onto: this is not an entity-level audit/change-log bundle. It will not tell you who edited a price record. If that requirement is also on the table, it's a separate decision — don't let one roadmap conversation conflate the two.

When to Consider This Package

Consider adopting when:

• The product is Symfony 6/7 with Twig, and you're comfortable with bundle registration plus a YAML config file.
• The runtime environment has the git binary and a full (non-shallow) clone — or you're willing to implement the bundle's Provider interface against a GitHub/GitLab/Jira API instead, which is often the better call for containerised deploys.
• You want a /changelog page or admin timeline now, and today's release notes are either missing or maintained inconsistently.
• Team git hygiene is decent enough that raw commit subjects are presentable, or you'll group by tag/version at render time.
• You accept a dependency on a very small maintainer (2 stars) with terse release notes — meaning: pin versions, read the diff, don't expect a support contract.

Look elsewhere when:

• The stack is Laravel or a non-Symfony admin — there's no first-class fit; you'll be fighting the integration rather than shipping.
• You need entity-change audit trails (who changed a record, field-level diffs). Different problem, different package.
• Hosts are hardened or ephemeral: proc_open on git is blocked in many PHP images, and --depth=1 clones silently produce a one-commit history that looks like a broken importer.
• You need regulator-grade, immutable, tamper-evident record-keeping. This is a convenience changelog, not a system of record.
• You need editorial, curated release notes with marketing voice — a raw commit stream won't satisfy that without a curation layer you build.

On V1.1.0 specifically: the release ships with only a compare link and no enumerated changes. Treat the minor bump as low-risk but unverified: diff vendor/spiriitlabs/commit-history-bundle between V1.0.1 and V1.1.0 and check for renamed config keys, entity schema changes, renamed console commands, and new Symfony/PHP constraints before upgrading. Keep the recommendation at "evaluate/pilot" until then.

How to Pitch It (Stakeholders)

For executives: "We can publish an always-current product changelog — automatically, from the commits engineering already writes — and optionally surface a 'What's new' panel inside the app. It removes a documentation chore from the team, shortens dispute and support conversations by making 'what shipped and when' answerable in seconds, and gives us a low-cost transparency signal. The trade-offs are modest: an extra MIT-licensed dependency, a small integration slice, and ongoing storage/pipeline hygiene. It also only fits our Symfony admin — it is not a decision we can carry over to a Laravel product, and it is not a compliance-grade audit system."

For engineering: "A Symfony bundle: bundle class, a config file owning the git repository path, a Doctrine entity plus an import console command, and Twig templates for rendering the vertical timeline. Integration is config plus one schema migration; the real work is operational, not code. Wire the import into the deploy pipeline after git pull — never per-request — and confirm the clone is full-depth. Rely on hash-based idempotency so re-runs are no-ops; if the installed version doesn't upsert by hash, wrap the command and dedupe. On hosts without a git checkout, implement the Provider interface against the GitHub/GitLab API rather than shipping a repo into the web container. Override Twig templates under templates/bundles/CommitHistoryBundle/ — anything patched in vendor/ disappears on the next composer update. Two things to own deliberately: sanitise commit message bodies before rendering as HTML (public page, attacker-controlled via outside PRs), and store UTC timestamps with formatting at render. Pin the version and review the vendor diff each release — V1.1.0 shipped with no written notes. If the requirement grows toward true audit trails or curated release notes, flag it early so we plan for it rather than retrofitting."