Version Bundle Laravel Package

Product Decisions This Supports

• Release visibility & support triage — surfacing the deployed version/commit in an app footer, admin panel, or /version endpoint so support and on-call can map a bug report to an exact build. This is the core decision it enables: "is this customer on the build that has the fix?"
• Rollback vs. hotfix — commit/branch metadata lets incident responders decide whether to roll back to a known-good artifact or patch forward, rather than guessing from timestamps.
• QA and staging verification — confirming the artifact under test is the artifact that was promoted, which reduces "works on staging" disputes.
• Build vs. buy vs. skip — the package's real value in a roadmap conversation is as a baseline for a build-vs-buy call: it is a small, single-purpose bundle, which means the honest comparison is "a few hours of engineering" against "an unmaintained dependency."
• Audit/regulatory evidence — for teams that need to show which version was live on a given date, in-app version stamping is cheap evidence; this package is a candidate only in a frozen legacy context.
• Out of scope — it does not provide feature flags, A/B testing, semantic-version enforcement, changelog generation, or deployment orchestration. Do not let it be scoped into those roadmap items.

Adoption signal: 3 stars, 0 dependents, archived. Treat as a reference implementation, not a dependency.

When to Consider This Package

Consider only if all of the following hold:

• You are maintaining a legacy Symfony 2.x application (this is a Symfony bundle, not a Laravel package — no service provider, no publishable config, no Laravel integration path without a port).
• The runtime is pinned to the PHP 5.x/7.0-era stack that Symfony 2 requires, so you cannot adopt a modern alternative anyway.
• The requirement is strictly read-only version display — no telemetry, no gating, no runtime behavior changes.
• Your organization has explicitly accepted an archived, unmaintained dependency, with a documented exit plan (typically: vendor the ~few hundred lines or replicate the logic in-house).
• No security/compliance policy prohibits abandoned packages in the dependency graph.

Look elsewhere if:

• You are on Laravel — you would be porting a Symfony DI extension for a trivial feature. Not worth it.
• You are on PHP 8.x / Symfony 5–7 — API and container conventions have moved on; expect compatibility work with zero upstream support.
• You need a maintained dependency with CVE response, or your supply-chain policy requires active maintenance.
• You need version data in CI/CD, error tracking, or observability (Sentry release tagging, health endpoints, deploy markers). Those are better served by build-time injection of git describe output than by a runtime bundle.
• You need feature flags, staged rollouts, or experiment assignment — different category entirely.

Cheapest viable alternative in most cases: inject a version constant at build time (from a git tag or CI variable) and expose it via a config value and a /version or /health endpoint. This is typically an afternoon of work, has no dependency risk, and works identically in Laravel and Symfony.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated zenstruck/version-bundle, a small library that displays an application's version inside a Symfony app. It solves a real but narrow problem — knowing which build is live — which helps support resolve tickets faster and helps incident response decide between rollback and hotfix. However, it is archived, has three stars and zero downstream users, and targets Symfony 2, a framework generation we do not run. Recommendation: do not adopt as a dependency. The capability is worth having; the package is not worth carrying. We can reproduce it in-house in roughly a day, with no maintenance or supply-chain exposure, and it will work for both our Laravel and any future Symfony services.

For engineering (the ask): This is a reference design, not a dependency. Port the concept, not the code: emit a version string at build time from the CI pipeline (git SHA + tag), store it in config, and expose it via an admin surface and a /version endpoint. Add the same value as a release tag in error tracking so alerts are version-scoped. Estimated effort: 0.5–1 day including tests. Skip entirely if our error tracker already reports release versions — in that case the marginal value is a UI convenience only.

Decision record: Adopt the pattern (build-time version stamping + /version endpoint), reject the package (archived, unmaintained, wrong framework generation, zero adoption). Revisit only if we inherit a Symfony 2 application where vendoring this file is faster than writing it.