Laravel Uuids Laravel Package

Product Decisions This Supports

• Platform/runtime upgrade timing: v3.0.1 raises the minimum PHP requirement to 8.0. Treat this as a forcing function for the PHP 8 migration decision rather than a purely technical dependency bump. Product should confirm whether the portfolio is already on PHP 8.0+ or whether this package becomes the catalyst for an infrastructure upgrade.
• Feature and roadmap gating: Any upcoming feature that depends on this package cannot ship to PHP 7.4 environments. Roadmap items should be sequenced after (or explicitly decoupled from) the platform upgrade.
• Build vs. buy: The adoption cost is no longer just integration effort—it now includes a platform baseline. If already on PHP 8.0+, "buy" remains low-friction. If on PHP 7.4, the true cost includes runtime migration, regression testing, and hosting changes.
• Plugin/interoperability strategy: The release explicitly targets "backwards compatibility with other plugins," suggesting this package is part of a multi-plugin ecosystem. If our product relies on or ships alongside other plugins, this release reduces integration risk and should be prioritized for compatibility testing.
• Support and maintenance policy: A patch-level version (3.0.1) that raises the PHP floor is effectively a breaking change for PHP 7.x consumers. Product should decide whether to pin the prior version for legacy customers or communicate an end-of-support date for PHP 7.4 deployments.

When to Consider This Package

Adopt when:

• The application already runs PHP 8.0 or higher, or a PHP 8 upgrade is already funded and scheduled.
• The Laravel version in use is compatible with PHP 8.0 and with this package's 3.x line.
• We depend on interoperability with other plugins in the same ecosystem—this release is specifically aimed at cross-plugin compatibility.
• We want a clean maintenance baseline and prefer to avoid running unsupported PHP versions.

Look elsewhere or defer when:

• The product is locked to PHP 7.4 or earlier (shared hosting, legacy Laravel, hard third-party constraints). Stay on the previous package version and document the risk.
• We cannot run a regression suite against PHP 8.0—this release is a platform gate, not a drop-in patch for legacy environments.
• We need long-term support for older PHP runtimes; this package's direction is clearly forward-only.
• The package's core functionality is peripheral to the product and does not justify a platform upgrade on its own.

How to Pitch It (Stakeholders)

For executives: v3.0.1 is a small maintenance release with one material implication—it formally requires PHP 8.0. That aligns us with currently supported PHP versions and improves compatibility across the plugin ecosystem. The functional risk is low, but it is a platform gate: teams on older PHP cannot take this update until they upgrade. Recommendation is to bundle this into the existing PHP 8 migration rather than treat it as a standalone project.

For engineering: Confirm CI and production runtimes are on PHP 8.0+, verify Laravel and transitive dependency compatibility, and run the full regression suite plus any plugin integration tests. Note that raising the PHP floor in a patch release is technically a breaking change for 7.x consumers—pin the prior version wherever an upgrade is not yet possible, and record the decision so legacy branches are not accidentally updated.