Nova Permission Tool Laravel Package

Technical Evaluation

Architecture fit. v2.0.0 is a constraints-and-support release rather than an architectural one. The package remains a conventional Laravel library (service provider registration, config publish, facade/contract surface implied by its Laravel integration), so nothing in this release changes how it slots into an application's layering. What changes is the addressable application population: the supported window is now Laravel 5.8–6.x on PHP 7.2+. That is a coherent, internally consistent window, but it is also a legacy window — it excludes both older L5.7-and-below estates and any modern Laravel line above 6. Any team currently on L9+ should read this release as "no forward path yet," not "upgrade available."

Integration feasibility. Mechanically low-friction: a Composer constraint change (composer require bump to ^2.0), a PHP runtime check, and a lockfile refresh. The feasibility question is therefore not effort but eligibility — an application on PHP 7.1 or Laravel 5.7 cannot take this version at all, and the version is a major bump, so SemVer convention obliges us to assume breaking API changes beyond the stated platform constraints. The notes only describe the platform floor; they do not enumerate renamed methods, changed config keys, or altered defaults. We should plan as if at least some exist.

Technical risk.

• Transitive constraint risk (highest). The note explicitly attributes the new requirement to "the upstream package." Our supported Laravel/PHP floor is therefore set by a third party's release cadence, not ours. That is a governance concern: their next major can strand us, and their end-of-life becomes our end-of-life.
• Breaking-by-declaration. Dropping L5.7 and older is a hard break for any consumer that cannot move; there is no deprecation runway described.
• Unverified upper bound. "Laravel 6" as a ceiling with no statement about 7+ and no statement about PHP 8 means the practical support envelope is narrower than the headline and must be tested, not assumed.
• Silent runtime change. Platform-floor releases frequently carry bundled behavioural fixes; without a linked diff or changelog, we cannot distinguish constraint-only from behaviour-changing.

Key questions.

1. Is v2.0.0 only a constraint change, or does it include API/signature/behaviour changes? Please supply the comparison link or CHANGELOG diff.
2. Which upstream package and version range drives the L5.8/PHP 7.2 floor, and what is that upstream's published support timeline?
3. What is the intended Laravel 7+ / PHP 8 roadmap and rough date? This determines whether we adopt v2 or hold.
4. Will the 1.x line continue to receive security fixes, and for how long?
5. Is there a documented deprecation list for anything removed alongside the L5.7 drop?

Integration Approach

Stack fit. v2.0.0 fits estates that are already on L5.8/L6 and PHP 7.2–7.4. It does not fit L5.7-or-older estates at all, and it should be treated as unsupported-by-vendor on L7+ until explicitly confirmed. The correct framing for stakeholders: this is an alignment release that keeps us on the package's supported line, not a modernization step.

Migration path.

1. Inventory. Enumerate every application and internal package depending on this library, recording Laravel version, PHP version, and current constraint.
2. Partition. Split into (a) already-eligible — L5.8/L6, PHP 7.2+; (b) PHP-blocked — needs a PHP upgrade first; (c) Laravel-blocked — needs framework upgrade, likely a larger project.
3. Pin, then move. For cohorts (b) and (c), pin to the last 1.x release and record it as technical debt with an owner and a target date. Do not leave them floating on a ^1||^2 style constraint, which risks an accidental cross-major resolve.
4. Pilot. Upgrade one low-traffic, well-tested application in cohort (a) first; run the full suite plus a smoke pass over every feature that touches the package.
5. Fan out. Roll to remaining cohort (a) applications only after the pilot confirms no behavioural drift.

Compatibility. Verify the full matrix in CI, not just the target cell: L5.8 and L6, PHP 7.2/7.3/7.4. Add PHP 8 and L7+ rows as expected-fail so a future upstream release is detected rather than discovered in production. Where the package's own dependencies (framework-adjacent helpers, HTTP clients, test tooling) are version-pinned, check they resolve inside the same window; constraint conflicts typically surface here rather than in the package itself.

Sequencing. PHP upgrade → framework upgrade (if needed) → this package. Attempting the package bump first will simply fail resolution and produce noise. Where a framework upgrade is out of scope this cycle, the honest sequence is: stay on 1.x, document the exposure, revisit next planning cycle.

Operational Impact

Maintenance. We inherit a two-track maintenance obligation: cohort (a) on v2, cohorts (b)/(c) on v1. That doubles the surface for compatibility testing and for internal patches. The larger ongoing cost is the upstream coupling — someone must actively monitor the upstream package's releases, because our framework ceiling is a function of theirs. Assign that watch explicitly; unowned dependency monitoring is the most common way this class of risk materializes.

Support. Confirm in writing whether the vendor supports v1.x after this release and for how long. If v1 goes end-of-life on a short clock, cohorts (b) and (c) are on a deadline and should be scheduled, not deferred. Also confirm the package's documentation has been updated to reflect the new floor — stale install instructions generate a predictable stream of internal support tickets.

Scaling. Not a runtime scaling concern; this is build-and-CI scaling. Supporting two major versions means a wider CI matrix, multiple Docker base images, and duplicated fixture setup. In a large estate this is the dominant cost of the release, so budget CI minutes and pipeline maintenance, not just engineering hours.

Failure modes.

• Resolution failure at install — the benign, early, loud failure. Preferred outcome.
• Clean install, runtime fatal — breaking API change not described in the notes. Mitigated by the pilot and full-suite run.
• Clean install, silent behaviour change — the dangerous one. Mitigated by characterisation tests around package-touching features before the bump.
• Accidental cross-major upgrade — a permissive constraint resolving v2 into a cohort (b) application during an unrelated composer update. Mitigated by hard-pinning 1.x for those cohorts.
• Upstream abandonment or yank — the package's floor and future are externally owned; treat as a standing supply-chain risk with a named owner and a contingency note.

Ramp-up. Low individual effort: roughly a half-day to a day per eligible application for a constraint bump and regression pass, plus the same again for verification. Budget separately for the inventory and the CI matrix, which are the real work, and treat framework-blocked applications as their own project rather than as part of this release.