Laravel 5.8

Laravel 5.8 raised the minimum PHP requirement to PHP 7.1.3. It added convention-based policy discovery, allowing policies in the expected namespace and naming pattern to be resolved without every model-to-policy mapping being registered manually. Eloquent gained has-one-through relationships. The cache API changed an important unit convention: integer TTL values are interpreted as seconds rather than minutes, so cache writes and tests that use numeric expirations need review when moving from the preceding line.

Laravel 5.8 has reached end of life, so it no longer receives vendor security fixes, bug fixes, or compatibility updates. Remaining on it leaves the application dependent on an old PHP baseline and an aging dependency set, which can make newer operating-system images, PHP runtimes, database clients, and third-party packages harder to adopt. The risk is not only a known framework defect: teams may need to pin dependencies, retain obsolete runtime components, or carry local patches when a security or compatibility issue appears.

Select a currently supported Laravel target that is compatible with the application and its required packages, then plan the move through the intervening major-version upgrade guides rather than treating it as a dependency-only update. Inventory the Composer lock file, PHP version and extensions, database and cache drivers, queue workers, authentication packages, and any packages that replace Laravel defaults. Build regression coverage around authorization decisions, cache expiration, queued jobs, mail, database queries, and Eloquent relationships. In particular, verify every numeric cache TTL is expressed in seconds and confirm that policy resolution remains explicit where convention-based discovery could select an unintended policy. Perform the upgrade in a reproducible staging environment, resolve deprecations and package constraints at each step, and deploy only after worker restart, rollback, and production smoke-test procedures have been exercised.