Eloquentencryption Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 9 / PHP 8.0+): v4.0 confirms this package tracks the modern Laravel baseline. If your roadmap includes a Laravel 9 migration, this package is no longer a blocker — but it also means v4.0 is a hard cutover, so sequencing matters.
• Build vs. buy for secure transport/crypto plumbing: The dependency on phpseclib/phpseclib indicates the package wraps non-trivial, security-sensitive protocol work (SSH/SFTP/encryption primitives). That is generally a "buy/adopt" decision rather than an in-house build — reimplementing this is not differentiated value for your product.
• Security posture and dependency hygiene: The bump to phpseclib 2.0.37 is a maintenance/security-driven update. This supports a decision to keep the package on a supported patch line rather than pinning an older release for convenience.
• Support-matrix commitments: A major version that raises minimum PHP to 8.0 lets you decide whether to publish a PHP 8.0+ support policy, and lets you retire CI coverage for PHP 7.x and Laravel ≤8.
• Vendor/risk triage: The release signal is "version alignment + dependency patch," not "new capability." For roadmap purposes, treat this as a maintenance release with a breaking support-floor change — no new user-facing features to plan launches around.

When to Consider This Package

Consider adopting (or upgrading to v4.0) when:

• Your application is on Laravel 9+ and PHP 8.0+, or will be within the current planning cycle.
• You need battle-tested protocol/crypto plumbing (SSH/SFTP/encryption) rather than a bespoke implementation, and you want that surface maintained by a third party.
• You are already running this package on Laravel 8 / PHP 7.x and have a defined upgrade window — v4.0 is the forward path, but it is not an in-place minor bump.

Look elsewhere or defer when:

• You are still on Laravel ≤8 or PHP 7.x with no migration date. v4.0 will not install; you would be stranded on v3.x and receiving no further fixes — an unsupported-branch risk to log explicitly.
• You need capabilities beyond what a phpseclib-backed wrapper provides (e.g., managed key rotation, audit logging, compliance attestation). Those are app-layer or vendor concerns, not this package's job.
• The dependency's phpseclib major line (still 2.x here) conflicts with your security policy requiring the 3.x line — confirm the maintainer's upgrade path before committing.

Adoption criteria to verify before rollout: confirm v4.0's changelog scope is truly limited to framework/PHP floor + dependency patch (no silent API changes), run the existing integration test suite against PHP 8.0 and 8.1, and confirm a maintained v3.x security-backport policy exists for any team that cannot move yet.

How to Pitch It (Stakeholders)

For executives: This is a routine but breaking maintenance release. v4.0 aligns the package with Laravel 9 and PHP 8.0+, and pulls in a patched version of its underlying crypto library (phpseclib 2.0.37). No new product capabilities — the business value is reduced security and platform-support risk. The cost is an upgrade task, not a feature investment.

For engineering: Treat v4.0 as a major-version migration. Minimum supported platform moves to Laravel 9 / PHP 8.0+, so anything on Laravel 8 or PHP 7.x must either migrate or be formally parked on the unsupported v3.x branch with an owner and an expiry date. The phpseclib bump is a security-relevant patch — prioritize it in the next dependency cycle. Validate against the full integration suite on PHP 8.0/8.1; watch for any undocumented API surface changes that the release notes do not call out. Recommend pinning the patched phpseclib floor in composer.json so the fix cannot be inadvertently downgraded.