What's the best way to keep up to date with new PHP versions?

PHP is pretty fast moving with multiple maintained versions - a quick search of the package repo shows that FreeBSD packages 8.0 through 8.3. I run a couple different web services for personal use which require PHP, but I'm not a PHP developer and I don't really keep track of when new PHP versions release and when others go EOL (coincidentally I did a quick check and apparently today is the day that 8.0 goes EOL, so if I were using 8.0 this would be a now problem and not a down the road problem).

I use 8.2 for the stuff I run, not for any particular reason, it was just what was most current and had all the packages I needed when I most recently set up the jails for them. But eventually (in about two years if Wikipedia is to be believed), 8.2 will be EOL and I'll need to move to a newer version. I regularly update my jails with pkg upgrade of course, but as it stands this will only update my packages to the latest 8.2 version - two years from now I'm going to stop seeing updates to my PHP version and have to manually convert all my php82 packages to php84 or 91 or whatever is current at that time. This is going to be a bit of a hassle to have to do manually.

What is the best way to handle this? On a server with 15+ different php82-* packages, what's the best way to convert each of them to their php83 (or higher) equivalent? I know some packages have meta ports that do this, where there would be a generic non-versioned package that tracks the latest stable release regardless of specific version, but I don't see one for php. Do I just need to keep an eye on support windows and do manual upgrades when the time draws near? Or is there some way to have the pkg utility handle the move for me as part of my normal updates without jumping through extra hoops?
 
Newsfeeds are unfortunately dying out a little, but they are perfect for staying up to date. Once upon a time, web browsers indicated the existence of such a feed, today there is no longer even an official link on the website...:

https://www.php.net/releases/feed.php

This in the newsreader to your other feeds (currently I'm using net/quiterss), and you're always informed about new versions.

And of course you have a test & development environment; If a new version appears in the feed, I'm reading the changes (www.php.net always offers a "changelog and an "upgrade" for each version); Initially only the development machine is upgraded to the current version. The webservers error log is available via sysutils/root-tail on the desktop background, so I easily can see whether the new version is causing work or can be used directly.

And regarding "how to update the packages" there is an entry in /usr/ports/UPDATING from 20221126; This is of course a stupid place for people who don't use ports at all but packages… I'm doing it differently myself: I keep a list of those PHP packages that I actually need (I don't need to take care of ones that came via dependency - and if a dependency is omitted in the future…); I then uninstall all those PHP packages (pkg info | grep php should have none output), and then reinstall only those packages that I really want.
 
The best way is to build from source. I'm on 7.4 and will stay there until there's a reason to upgrade. I have some customized stuff so using pkgs is a PITB. If I need a module, I just add it to config and recompile. Make install is clean and there's really only 2 items; the http module and the cli. So its very clean and you don't have to use whatever the pkg guy feels like doing. Unlike other programs, upgrading php will invariably break something you wrote 3 years ago. I like to compile modules into the core so I don't have to deal with module versions and moved directories and other nonsense. PHP is a really good platform to do almost anything but the developers are a bit nutty in how they tell you to do things.
 
The best way is to build from source. I'm on 7.4 and will stay there until there's a reason to upgrade. I have some customized stuff so using pkgs is a PITB. If I need a module, I just add it to config and recompile.
There are modules in the PHP source that aren't offered as port/package? Today there is really no need to go with the PHP source since a dozen of years, and I'm glad those days are over (been there…). If I need a module of the source I'm using pkg install. Much more convenient than recompiling and installing the whole thing.

PHP 7.4…: You can do that if you're PHP scripts are just running locally in your own network. But on a public server: PHP 7.4 is EOL, and it's up to you to upgrade your PHP scripts, too. Always. And there's always plenty time to do that (as 8 came out 7 wasn't droped immediately). A server with outdated software and unmaintained scripts are a bad thing for others, as hacked servers are used to attack others. I'm developing really huge and complex web applications for companies, and upgrading the code after you're really done your homework at the 5 to 7 switch was trivial.

"It works" is not enough on a public server.
 
7.4 is EOL and doesn't receive security updates anymore. Is that enough of a reason?


Edit: Ooops, jmos beat me to it.
And why do I care if it's EOL if there are no bugs? People are just so dumb about updating their system every time there's some new code. I have to upgrade 30 systems running my php code perfectly well because some dweeb has a new idea about how to do something? I used Freebsd 9.x for 5 years because 10, 11 and 12 sucked rocks.
 
Newsfeeds are unfortunately dying out a little, but they are perfect for staying up to date. Once upon a time, web browsers indicated the existence of such a feed, today there is no longer even an official link on the website...:

https://www.php.net/releases/feed.php

This in the newsreader to your other feeds (currently I'm using net/quiterss), and you're always informed about new versions.

And of course you have a test & development environment; If a new version appears in the feed, I'm reading the changes (www.php.net always offers a "changelog and an "upgrade" for each version); Initially only the development machine is upgraded to the current version. The webservers error log is available via sysutils/root-tail on the desktop background, so I easily can see whether the new version is causing work or can be used directly.

And regarding "how to update the packages" there is an entry in /usr/ports/UPDATING from 20221126; This is of course a stupid place for people who don't use ports at all but packages… I'm doing it differently myself: I keep a list of those PHP packages that I actually need (I don't need to take care of ones that came via dependency - and if a dependency is omitted in the future…); I then uninstall all those PHP packages (pkg info | grep php should have none output), and then reinstall only those packages that I really want.

And who is talking about a public server? The OP specifically said "personal use". EOL simply means the code is frozen, which is a good thing.You have source. I don't need the new features; I can fix bugs myself. PHP is particularly bad because they insist on removing and deprecating functions for no reason. "Oh, we don't like that function anymore, lets get rid of it and create some cool new class to replace it"
 
And who is talking about a public server? The OP specifically said "personal use".
  1. "Personal use" could be a public blog.
  2. Your answer "how to stay on an old version" wasn't asked; The OP asked about how to stay up to date ;)
PHP is particularly bad because they insist on removing and deprecating functions for no reason.
The deprecations I saw were communicated years before they are removed. I recommend increasing the error level wherever the development happens.

And the bad reputation should be blamed on the disastrous developers - not the language; True, there were some bad ideas at the beginning years of PHP, but 13 years ago f.e. register globals weren't usable for a high traffic system anymore (5.3) etc.; And with PHP 8 users need to write again a cleaner code than with 7 - which is a good thing: Many code I saw was cobbled together by the clueless; Those who paid attention to easiest programming basics have had exactly zero problems to move from 7.0 to 8.3 - but those who have put together lazy code have. IMO & sorry, but: Those who moan belong to the latter group.
 
  1. "Personal use" could be a public blog.
  2. Your answer "how to stay on an old version" wasn't asked; The OP asked about how to stay up to date ;)

The deprecations I saw were communicated years before they are removed. I recommend increasing the error level wherever the development happens.

And the bad reputation should be blamed on the disastrous developers - not the language; True, there were some bad ideas at the beginning years of PHP, but 13 years ago f.e. register globals weren't usable for a high traffic system anymore (5.3) etc.; And with PHP 8 users need to write again a cleaner code than with 7 - which is a good thing: Many code I saw was cobbled together by the clueless; Those who paid attention to easiest programming basics have had exactly zero problems to move from 7.0 to 8.3 - but those who have put together lazy code have. IMO & sorry, but: Those who moan belong to the latter group.

First of all, you have it completely backwards (not surprising). I merely said I was using an old version because I don't want to update my systems every 3 days. If you moved from 7.0 to 8.3 with "no problems" you aren't doing anything serious

If you want to stay "up to date", then you can't use pkgs, because they're always months behind. Source is the ONLY Way to stay "up to date", if that's your goal. The current pkg version is 8.2.11 and 8.2.13 is out. So you'll always be behind.

The "BEST" way to use PHP in general is to download the source. Check the release notes, if you care about something new or that's been fixed, download a tarball, run config, make, install and you're up to date without having 75 murky pkgs on your system.

With source you can also compile in the modules you need rather than having to load a module file for every extension you use. It's much cleaner
 
I merely said I was using an old version because I don't want to update my systems every 3 days.
Stick to the quarterly branches and at least update once every three months (and additionally, if some security issue pops up). You don't need to update every couple of days. I upgrade on a weekly basis, other's do it once a month. Find a schedule that works for you, but at least schedule something regularly.

If you moved from 7.0 to 8.3 with "no problems" you aren't doing anything serious
Although you use quarterly, keep an eye on the 'latest' ports/packages. Then you know in advance what you're getting into when a new quarterly is branched off.

If you want to stay "up to date", then you can't use pkgs, because they're always months behind.
No. Quarterly is more or less 'frozen' over a period of three months. It only receives security updates. It's specifically meant for people like you.
 
Stick to the quarterly branches and at least update once every three months (and additionally, if some security issue pops up). You don't need to update every couple of days. I upgrade on a weekly basis, other's do it once a month. Find a schedule that works for you, but at least schedule something regularly.


Although you use quarterly, keep an eye on the 'latest' ports/packages. Then you know in advance what you're getting into when a new quarterly is branched off.


No. Quarterly is more or less 'frozen' over a period of three months. It only receives security updates. It's specifically meant for people like you.
"People like me". Funny stuff.
 
You are a bit screwed with PHP. Since it doesn't have compile-time type checking you lack the first defense against even recognizing that a new version of a library is incompatible. I hope you have good tests on your own.

Following non-quarterly packages is probably hopeless if you can't contiguously test and update your own code. Not to mention it might become broken at any time.

The best option probably is to have a /opt/php/{bin,lib,share}/ where you compile your own picked versions from source. But then you have to watch out for updates available on your own.
 
If you moved from 7.0 to 8.3 with "no problems" you aren't doing anything serious
Actually: PIM, DAM, print/catalog automation, ERP connections (im- & exports), some WMS specialties, translation management (dozen languages), ticket system, CMS & websites, wiki etc.; Global acting companies with multi million volumes of sale and more than one brand. And all programmed from scratch as self-emploeyd one man show (my problem: trust; as you wrote one f.e.: "well, if you're not having the problems we have you're not playing with the big kids").

I know exactly what you're talking about. Over a dozen years ago I've been working as employed software developer, our customers were global players with complex setups. They had practically no chance to change their complex setup and had to fulfill the requirements of the chosen software - including a self-compiled PHP with countless dependencies. They were trapped.

It is solvable. Done it. You then have very grateful customers. EOT4me.
 
I didn't say "big kids". Nobody would say that out lould

Of course it's "solvable". It just a PIA and not necessary/ There's just no reason to upgrade just for the heck of it; the same reason I don't update my iPhone just because there's an update. Nothing to be "trapped" about ; All they really do is make it more finicky; add more and more exceptions. Make it less programmer friendly. There's absolutely no reason to run 8.3 unless someone is telling you you have to run the latest stuff. I don't have that person. Their new classes blow so there's nothing really new, and 7.4.33 is very solid. Sure, I can spend my time adding try-catch loops to every function or fixing code I wrote 10 years ago and forgot to declare a class (stuff that php used to handle but now barfs all over the screen), but it's unnecessary. I have a build too I use that doesn't run in v8 , is unsupported (a big Git project) and I can't do without it. So I keep a v7.3 binary on my system just to run that tool. Is it "solvable"? Could I spend a week fixing it? sure, I don't have time for it. AND THERE IS NO REASON TO. It won't add one iota of utility to my life if I do.

The only people who are "trapped" are the ones forced to update their pkg just because a new something is out.


Back to the OP. I need to run 8.2.13 for some fix. How do I di it with FreeBSD Pkg? I can't. I can download the source and run it in 5 minutes. So what does "up to date" mean? Up to date on what is available for FreeBSD in the Pkg system, or what is actually cutting edge? PHP is 2 files. a CLI and an http module. There's no cleaner way to utilize PHP. Version unimportant.

BTW, 8.0 is now EOL so why is it in the pkg system still? Get it out of there! Can't have people using EOL stuff.
 
You are a bit screwed with PHP. Since it doesn't have compile-time type checking you lack the first defense against even recognizing that a new version of a library is incompatible. I hope you have good tests on your own.

Following non-quarterly packages is probably hopeless if you can't contiguously test and update your own code. Not to mention it might become broken at any time.

The best option probably is to have a /opt/php/{bin,lib,share}/ where you compile your own picked versions from source. But then you have to watch out for updates available on your own.

The point is it doesnt matter. There's no real difference running php 7.3, 7.4 or 8.3 except religion.
 
Back
Top