File Vault Laravel Package

Getting Started

v1.2.0 is a compatibility-only release: PHP 7.1 support has been dropped. There are no documented feature changes, so the practical upgrade surface is your runtime version and your Composer constraints, not your application code.

Start by confirming the new floor rather than assuming it:

composer show vendor/package --all | grep -A2 requires
# or read the raw manifest
curl -s https://raw.githubusercontent.com/vendor/package/v1.2.0/composer.json | jq '.require'

Expect "php": "^7.2" (or >=7.2, or in some packages ^7.2 || ^8.0). Cross-check that against your own composer.json require.php and your deployed runtime (php -v, phpinfo(), your Docker base image tag).

Your first real use case is a dry-run upgrade in a project that is already on 7.4/8.x:

composer update vendor/package --with-dependencies --dry-run
composer update vendor/package --with-dependencies
php artisan vendor:publish --provider="Vendor\\Package\\ServiceProvider" --tag=config # if applicable
php artisan config:clear && php artisan cache:clear

If you are still on PHP 7.1, do not upgrade — pin ^1.1 and plan the PHP upgrade as a separate, larger piece of work. Since this release contains no behaviour changes, the upgrade is a drop-in for anyone already on 7.2+; treat a failing suite after upgrade as a pre-existing latent issue that the version bump merely surfaced, not as a regression introduced by v1.2.0.

Implementation Patterns

Constraint strategy. Use the PHP floor as the discriminator in your composer.json rather than hard-pinning an exact version:

{
  "require": {
    "php": "^7.2",
    "vendor/package": "^1.2"
  }
}

For libraries you publish yourself (as opposed to applications), keep the constraint permissive — "vendor/package": "^1.1 || ^1.2" — so downstream consumers on either side of the PHP 7.1 cut still resolve.

CI matrix alignment. Removing a PHP version from the package is a signal to re-check your own matrix. Keep the lowest PHP you test on in sync with the lowest you claim to support, and let Composer enforce it:

# .github/workflows/test.yml
strategy:
  matrix:
    php: ['7.2', '7.4', '8.0', '8.1']
steps:
  - uses: shivammathur/setup-php@v2
    with: { php-version: '${{ matrix.php }}', tools: composer:v2 }
  - run: composer update --prefer-lowest --prefer-stable
  - run: composer check-platform-reqs
  - run: vendor/bin/phpunit

The --prefer-lowest leg is where a PHP-floor change actually bites, because it resolves the oldest satisfying dependencies — exactly the combination your production image may resemble.

Staged rollout. Because v1.2.0 is behavioural no-op, upgrade it in the same PR as unrelated maintenance work rather than its own release train — but do it before you start adding PHP 8-only syntax or attributes to code that touches the package. Getting the constraint raised early means your static analysis (PHPStan/Larastan at level: max) starts checking against the modern signature set sooner.

Local/runtime parity. In Laravel apps, the package is normally auto-discovered, so no config/app.php edit is needed. Verify discovery is intact after upgrade:

php artisan package:discover
php artisan about          # Laravel 9+

Gotchas and Tips

• A minor version dropping a PHP version is semver-legal but not risk-free. ^1.1 will happily resolve to 1.2.0, and any consumer still on PHP 7.1 breaks at install time rather than at runtime. If you support older environments, constrain explicitly (>=1.1 <1.2) or add "config": { "platform": { "php": "7.1.33" } } to lock resolution — just remember the platform config is an install-time fiction, not a runtime guarantee.

• Beware platform overrides hiding the truth. If config.platform.php is set in your root composer.json, composer update will succeed on a machine whose real PHP is too old (or too new). Always verify with composer check-platform-reqs after install, ideally in the same container image you deploy.

• Debugging resolution failures — the fastest path is asking Composer why:

  composer why-not vendor/package 1.2.0
  composer show -t vendor/package      # dependency tree
  composer prohibits vendor/package    # who is blocking the version
  

  The usual culprit is a second package that still requires php: ^7.1 or a Laravel version pinned to an older framework that caps the transitive graph.

• Docker/CI drift. php:7.1-fpm base images and old shivammathur/setup-php matrix entries are the classic failure mode. Grep your repo for 7.1 across Dockerfile, .github/, .gitlab-ci.yml, docker-compose.yml, and .tool-versions before bumping.

• Laravel version coupling. Laravel 6 was the first release to require PHP 7.2. If this package's floor now matches, note that your effective support matrix is now max(package floor, framework floor) — document it once, in the README, so the next bump isn't archaeology.

• Extension points to audit after any version bump, even a compatibility-only one: published config files (diff config/package.php against the vendor copy with php artisan vendor:publish --force into a scratch dir), cache/session drivers the package registers, and any Provider::register()/boot() behaviour you rely on. A release that only touches the manifest still regenerates the lock file, which can quietly drag transitive dependencies forward.

• Verify the manifest actually matches the notes. Release notes say "removes php 7.1 support"; the authoritative statement is the require.php constraint. If the notes and manifest disagree, trust the manifest, and check whether composer.lock in your app changed more than the single package — that diff is your real change surface.

• Pin your CI cache key to composer.lock. After a floor bump, a stale Composer cache keyed on a hash that doesn't include the lock file can serve a resolved vendor tree built under the old PHP, producing confusing "works locally, fails in CI" results that look like package regressions.

No functional changes are documented for v1.2.0, so this assessment does not add usage patterns beyond the compatibility workflow above; re-review once a release ships behavioural changes and the package's actual API surface can be documented concretely.