Version Laravel Package

Product Decisions This Supports

• Release visibility and semver discipline. Gives the app a single source of truth for its version string (major.minor.patch plus build metadata like build number, commit SHA, and timestamp), which turns "what version are you running?" from a Slack archaeology exercise into a Version::get() call. This directly supports decisions about how strictly to enforce semantic versioning, who bumps versions, and when.
• Support and QA triage. Exposing build metadata in the footer, an /about or /status endpoint, or an API response header lets support and QA correlate bug reports to an exact build. This supports decisions around SLA targets, escalation paths, and whether to invest further in observability.
• Customer-facing trust and compliance. An accurate, auditable version label is a prerequisite for changelogs, release notes, status pages, and many SOC 2 / ISO 27001 evidence requests. This informs decisions about how much to invest in release documentation and audit readiness.
• Deployment provenance in CI/CD. The version:build command can stamp builds with git and date metadata, letting you decide whether build provenance lives in-app (cheap, coarse) or in a dedicated artifact/registry system (expensive, rigorous).
• API contract management. Surfacing a version in response headers supports decisions about API deprecation policy, client compatibility windows, and versioned endpoint strategy.
• Build vs. buy framing. This is a commodity capability. The real decision it informs is not "which package" but "do we buy a 591-star convenience wrapper or spend half a day writing ~30 lines ourselves?"

When to Consider This Package

Adopt when:

• You run a single Laravel monolith (or a small number of Laravel services) on a conventional deploy pipeline, and no existing release-metadata service exists.
• You need a fast, low-risk win: one Composer dependency, a config file, an artisan command, and a Blade/facade call. Hours, not sprints.
• Support/QA traceability is the actual pain — engineers are guessing which build a customer is on.
• You want semver plus build metadata without standing up semantic-release, GoReleaser, or a versioning service.
• Your team is comfortable accepting lightweight third-party maintenance risk for a very small, easily replaceable surface area.

Look elsewhere when:

• You need release orchestration, not version display: automated tag-driven versioning, changelog generation, artifact signing, SBOMs, or SLSA-style provenance. Use semantic-release/Goreleaser plus a registry; this package is not that.
• You run many services or polyglot stacks — a centralized deployment-metadata service or your CD platform's built-in build info is a better fit.
• You have security constraints on exposing VCS metadata publicly (private repo commit SHAs in a public footer). Verify exposure before shipping.
• The package's Laravel/PHP compatibility lags your framework version, or its maintenance cadence looks stale. With near-zero dependent packages, you are effectively the only safety net.
• You already have build info injected as environment variables by your CI — a config read is simpler than a new dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, cheap capability with a clear operational payoff: every customer, support agent, and auditor can see exactly which build is running. That shortens support resolution time, makes release notes and audit evidence trivially accurate, and removes a recurring "which version is in production?" ambiguity. Cost is a single MIT-licensed dependency and roughly a day of engineering, with no infrastructure change. The risk is low and reversible — the functionality is small enough that we can replace it in-house if the package ever goes stale.

For engineering: It standardizes how we derive and expose app version and build metadata — one facade, one artisan command, one config file, wired into our footer, /status, and API headers. It does not touch deployment, CI, or runtime behavior. Two caveats to flag: confirm compatibility with our Laravel/PHP versions and the package's recent commit activity before adoption, and be deliberate about whether commit SHAs are exposed publicly. If either caveat is uncomfortable, the fallback is a ~30-line internal helper reading a build file written by CI — same outcome, no dependency.

Recommendation: Approve a short spike to validate compatibility and pick exposure points (footer, health endpoint, response header). Treat it as a convenience layer, not a release-management strategy — pair it with a documented semver and tagging convention so the version string stays meaningful.