Nested Sets Laravel Package

Product Decisions This Supports

• Runtime modernization (PHP 8 upgrade program). v7.0.0 adds PHP 8 support, which unblocks (or de-risks) moving affected services off end-of-life PHP versions. This is a roadmap dependency for any "supported runtime" or security-patching initiative — treat it as an enabler, not a feature.
• Security & compliance posture. PHP 7.4 and 8.0 are both past end-of-life. The release raises the floor to 7.4 and opens the door to 8.x. If any of our services still run 7.2/7.3, this major version hard-blocks adoption until that's resolved — a scheduling input for the platform roadmap.
• Dependency policy / upgrade budget. The BC break is a version-floor bump, not an API rewrite. That's the cheapest class of major upgrade: a composer.json constraint change plus a regression pass. Useful precedent for how we scope "major version" work in planning.
• Build vs buy. A presenter/formatting layer is commodity glue. The existence of a maintained package with PHP 8 support argues for buy/adopt over an in-house layer, provided vendor-health checks pass (see below).
• Feature work in the presentation layer. The presenter bug fix affects how output gets rendered. Any product surface relying on that output should be re-validated rather than assumed unchanged — relevant to contract/snapshot test coverage decisions.

Evidence caveat: this assessment is derived solely from the v7.0.0 release notes. Package identity, maintenance activity, download volume, issue backlog, licence, and test coverage were not supplied and must be confirmed before adoption.

When to Consider This Package

Consider it when:

• The application is on PHP 7.4 or 8.x and can satisfy the new floor without a parallel platform migration.
• You need a presentation/formatting layer and would otherwise hand-roll one — the abstraction is small and the switching cost is low.
• You can absorb occasional major bumps as routine maintenance tickets rather than projects.
• A spike or snapshot suite exists to confirm the presenter fix doesn't shift rendered output on our data shapes.
• Vendor health checks pass: recent commits, responsive maintainer, compatible open issues, acceptable licence.

Look elsewhere when:

• You're on PHP 7.2/7.3 with no funded upgrade path; this release is unusable and older majors are a dead end.
• You need LTS, commercial support, or a formal deprecation policy — nothing in these notes indicates one.
• The presenter behaviour is load-bearing and undocumented; a bug fix shipping in a major with no migration notes is a yellow flag for a core-path dependency.
• The ecosystem you depend on (framework version, other packages) hasn't yet declared PHP 8 compatibility, making the upgrade net-negative in the short term.

How to Pitch It (Stakeholders)

For executives: This is a routine maintenance release for a small, low-coupling dependency. Its value is strategic rather than functional — it keeps us on a supported, security-patched PHP runtime, which reduces exposure and defers the cost of an emergency migration later. Cost is one scoped upgrade ticket (constraint bump + regression pass), not a project. Risk is contained because the breaking change is a minimum-version requirement, not a rewrite of how the code works.

For engineering: v7.0.0 raises the minimum to PHP 7.4, adds PHP 8 support, and fixes a presenter that wasn't being set correctly on 7.4. Actions: confirm our PHP floor, bump the constraint, and add a regression test around presenter output before merging — the fix changes behaviour on a path we may implicitly depend on. If we're below 7.4, this release is blocked until the platform upgrade lands; sequence accordingly.

Recommendation: Adopt v7.0.0 as part of the next scheduled dependency pass, gated on (a) confirming our PHP floor is ≥7.4, (b) a presenter-output regression check, and (c) a quick vendor-health review, since no prior assessment or package data exists to rely on.