2

Now that Laravel 5.5 supports only PHP > 7.0, what can I do to ensure that I can keep it compatible with 5.6.x? I am in a 5.6 environment, upgrading PHP is not an option, and I want to make sure that composer update will not break anything if its ran at any time in development environment.

Looking at articles it appears that downgrading is not easy, so I just want to make sure that somehow things don't get broken.

Here's the composer entry/dependency list, laravel is specified as 5.4.*

{
    "require": {
        "php": ">=5.6.4",
        "laravel/framework": "5.4.*",
        "laravel/tinker": "~1.0",
        "laravelcollective/html": "^5.4.0"
    },
    "require-dev": {
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "0.9.*",
        "phpunit/phpunit": "~5.7"
    },
}

So, does this mean I can no longer run composer update? Or am I still safe to update my other packages, e.g. the ones specified above, and laravel will stay 5.4.36?

I realize the specification in composer tells the package to stay in the 5.4.x range, I just want to make sure, and also I'm worried that the dependencies might not be safe at staying backwards compatible? I'm wondering if I should just forget about composer update for now, or if I need to more carefully adjust the composer.json.

Also note, my next projects that I spin up, will need to be PHP 5.6 as well, and I will be cloning from a customized laravel-base here, which will have "laravel/framework": "5.4.*", always, so will I be good as long as this is set that way?

Update

In response to @Eric Brown's answer, and some research on packagist, this is what I have adjusted the main dependencies (+ laravelcollective/html) to:

"require": {
    "php": ">=5.6.4",
    "laravel/framework": "5.4.*",
    "laravel/tinker": "1.0.*",
    "laravelcollective/html": "5.4.*"
},
"require-dev": {
    "fzaninotto/faker": "1.7.*",
    "mockery/mockery": "0.9.*",
    "phpunit/phpunit": "5.7.*"
},

I might init a new git repo with a copy of the Laravel/vendor files next, and then place this into a new directory, which I don't really want to mess with sub modules, so that may end up being a tarball instead, which can get commited with the original.

blamb
  • 4,220
  • 4
  • 32
  • 50
  • PHP 5.6 is [no longer actively supported and will receive security updates for only one more year](http://php.net/supported-versions.php). After that point, it will be dangerous and irresponsible to continue running it. **Now** is the time to start planning for a migration to PHP 7. – ceejayoz Dec 06 '17 at 21:26
  • Good point! It's up to the corp on that. Since I have no control over this aspect all I can do is give them something long term stable for their current infra, then adjusting the composer.json will be easy enough when they do decide to upgrade. Ill note your comment boldly in the readme or somewhere like that! – blamb Dec 06 '17 at 21:29
  • Make sure your `composer.lock` file is included in source control. It includes **exact** versions of everything installed at the time it's generated, and lets you do `composer install` to get those exact versions installed. A `composer update` will update the `.lock` file with new packages, so having it in source control means you can check out an old `.lock` file and downgrade back to those exact versions again. – ceejayoz Dec 06 '17 at 21:34
  • Thanks, I had thought of that this morning, that's the first thing i was going to do. The lock file and composer.json I will add to that tarball. – blamb Dec 07 '17 at 18:38

1 Answers1

1

By default, Laravel will not upgrade to newer versions of Laravel like that because, as you pointed out, in your composer.json file, the "laravel/framework": "5.4.*" specifies that Laravel must always be version 5.4.some_version_number. You shouldn't have to worry about backwards compatibility too much, but if you still want to receive updates on potential bugs or vulnerabilities, add a * instead of the last number, such as 4.3.* instead of 4.3.1.

Also, it would be very beneficial to learn how to use Git repositories such as Github or Bitbucket and store a current version in there. They are perfect for version control and ensuring that nothing goes too horribly awry in development or updates. This has personally saved me more times than I care to count.

Eric Brown
  • 1,312
  • 3
  • 15
  • 30
  • Are you suggesting that i store a "current version" of the framework itself, e.g. the `Vendor` folder, e.g. remove it from .gitignore, or maybe the entire `Laravel` folder, in a separate repo and save as a backup? And would you recommend that I add the asterix to `tinker`, `collective` and `faker` as well? – blamb Oct 31 '17 at 16:37
  • Yes, mainly because, in your instance, upgrading could cause something to go wrong if the updates only use PHP7, which is unlikely, but still possible. It's just an added layer of safety, should an update go wrong. – Eric Brown Nov 01 '17 at 15:30