Parameter Encryption Bundle Laravel Package

Product Decisions This Supports

• Dependency and platform-baseline planning. This release drops PHP 5.6 and 7.0 support and moves the test matrix to PHP 7.3 as the default. That sets a hard floor of PHP 7.1+ for any application or service consuming the package. Use it to decide whether to adopt, pin, or defer — and to sequence any PHP runtime upgrade work already on the roadmap.
• Build vs. buy / dependency risk scoring. The release is almost entirely internal hygiene: symfony/phpunit-bridge for deprecation surfacing, strict typing, PHPUnit 6.2+, PHP CS Fixer rule modernization, and Coveralls/Travis updates. That pattern is a positive maintenance signal — the maintainers are actively tracking toolchain and language evolution — and belongs in a vendor/dependency scorecard alongside commit cadence and issue responsiveness.
• Roadmap gating for legacy PHP estates. If any product surface still runs on PHP 5.6 or 7.0 (including long-lived client deployments or shared hosting targets), this version is not adoptable there. That is a portfolio-level constraint, not an engineering detail: it determines whether the package can be standardized across all products or only the modernized ones.
• Use-case fit is not resolved by this release. v1.2.0 introduces no new end-user capability. It does not expand the set of problems the package solves, so it should not be used to justify a new feature bet or a net-new adoption. Treat it strictly as a compatibility and quality signal.

When to Consider This Package

Adopt or upgrade when:

• Your runtime floor is already PHP 7.1 or newer and you can absorb the 5.6/7.0 removal without a parallel migration.
• You value strict typing in a dependency — it reduces the class of silent coercion bugs that surface as production incidents and shortens debugging cycles.
• You want deprecation warnings surfaced in CI rather than discovered at upgrade time; the symfony/phpunit-bridge addition is directly useful for teams planning future framework upgrades.
• You are standardizing on a PHPUnit 6.2+ test toolchain and want alignment rather than a second, divergent test stack.
• You are evaluating maintenance health as a tiebreaker between otherwise comparable packages — the CI and tooling refresh is a credible positive.

Look elsewhere or defer when:

• You are still on PHP 5.6 or 7.0, or ship to environments you do not control the runtime for.
• You need HHVM support — explicitly dropped, as HHVM no longer supports PHP.
• You require new functional capability; this release delivers none, so it is not a reason to adopt on its own.
• You are on a legacy PHPUnit and cannot upgrade the test harness alongside the package.
• The package's core domain fit is unproven — these notes describe engineering process, not problem domain, so functional evaluation still has to happen separately.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release, not a feature release. Its value is risk reduction: the maintainers have modernized their toolchain, dropped end-of-life PHP versions, and tightened type safety. In plain terms, the dependency is being actively looked after and is less likely to become a liability. The one decision it forces is a platform one — anything still running PHP 5.6 or 7.0 cannot take this version.

For engineering: v1.2.0 raises the PHP floor to 7.1+, adds strict typing, upgrades the test stack to PHPUnit 6.2+ with symfony/phpunit-bridge for deprecation notices, and refreshes PHP CS Fixer rules and CI. Expect deprecation output in test runs and possible strict-type failures in code that relied on implicit coercion. Verify your runtime and test harness before upgrading; the upgrade itself should be low-effort on a modern codebase.

Bottom line: Approve the upgrade where the PHP floor is already met — it buys us a healthier dependency at near-zero product risk. Where the floor is not met, log it as a known constraint against the PHP modernization roadmap rather than treating it as a package defect.