Laravel Version Laravel Package

Product Decisions This Supports

• Feature decisions: Exposing build/version in-product — footer, /about, admin panel, /health endpoint — so support and customers can answer "what version are you running?" without a deploy log dig.
• Observability decisions: Tagging error-tracker releases (Sentry release, APM, log context) so incidents correlate cleanly to deploys. This is the highest-value use case and usually the one that justifies adoption.
• Deployment verification: Post-deploy smoke checks asserting the running app reports the expected version — catches stale caches, partial rollouts, wrong container image, and "deployed but not really" failures.
• Cache busting / asset invalidation where the version string is a cache key or invalidation token.
• Build vs. buy: Frame this as glue, not platform. It's a thin abstraction over a trivial concern — budget hours, not a quarter. The build alternative (a config value, a VERSION file read, or a hardcoded constant) is viable for single-target apps. Buy/borrow only when you need multiple sources across environments.
• Source-of-truth roadmap: Adopting this forces a useful decision — does version truth live in the repo tag, the CI artifact, the container image, or config? The package is a forcing function for that conversation.
• Architectural decision: The port-adapter shape lets you start with a VERSION file for CI-built images and later swap to git tags or env vars without touching call sites. That de-risks the versioning debate and keeps the door open.
• Multi-tenant / white-label: The config-array source supports per-tenant or per-brand version strings without new plumbing.

When to Consider This Package

Consider it when:

• The app already needs version surfaced in more than one place and resolution logic is duplicated or hardcoded.
• You deploy multiple ways (containers, Forge, bare metal) and want one resolver with per-environment sources.
• You want testable version resolution — the port/adapter design lets you fake the source in tests instead of touching the filesystem or shelling out to git.
• You're standardizing release tagging across several Laravel services and want consistent plumbing.
• It's internal tooling, and you're willing to vendor the code.

Look elsewhere or don't adopt when:

• Maturity is the blocker. Zero stars, zero dependents, unvetted maintainer. Treat the code as a reference implementation: vendor it, pin the commit, or reimplement the ~100 lines in-house. The concept is trivial; the dependency is not worth trusting blindly.
• You need release management — changelog generation, semver enforcement, deployment orchestration, feature flags. This is a resolver, not a release platform.
• Git-tag reading will run in shallow clones or read-only containers; verify the fallback chain actually degrades the way you expect rather than throwing or returning empty.
• Supply-chain / compliance rules require vetted dependencies.
• Single deployment target and a single version string — a config value is enough; don't add a package for it.

Adoption checklist: audit the source, wrap it behind your own interface and container binding, add tests for precedence order and failure behavior (exception vs. silent fallback), and confirm it works in your actual build/runtime environment, not just locally.

How to Pitch It (Stakeholders)

To executives: A small, low-cost utility that answers one question consistently — what version is running? Its value is faster incident triage and safer deploys: support and on-call stop guessing, and post-deploy checks catch bad rollouts before customers do. Cost is engineering hours, not a roadmap item. The package itself is unmaintained, so we'd vendor the code and own it — the risk is near zero once we do.

To engineering: A port-adapter resolver with pluggable sources — VERSION file, env var, git tag, or config array. We bind one interface, pick the source that fits each environment, and swap sources later without touching call sites. Adapters are fakeable in tests. Recommendation: vendor or fork it, pin it, and write our own tests around precedence and fallback. Keep the abstraction; don't stake anything on the dependency.