Python 2 -> 3 change really was painful for Python community, but PHP does these almost fundamental breaking changes so often, that maybe people just get used to it? I haven't really followed Python past version 2, but I think they are less likely to ever do such amount of breaking changes.
There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
Edit: Those dogpiling there, I rest my case with josefresco's comment:
https://news.ycombinator.com/item?id=33907628
It's painful. Dropping dynamic properties? That will be a lot of fun. WordPress is probably biggest segment for PHP usage.
PHP 7 made a few big and necessary changes but they generally did not affect well-written code much. Python 3 broke a lot of things without good justifications, and without a way to make your code compatible with Python 2 at the same time.
PHP has gone through a few changes.
PHP 3->4 was a moderately big change under the hood, and introduced a lot of new things, but most 3 'worked' under 4 (but was... awkward).
PHP 4->5 - a few 'big' things changed - XML processing changed - I had to use some shims to get some projects upgraded.
PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects. I can't recall too many major breaking changes, but it was mostly just getting a doubling of speed without any substantive changes.
The PHP community has a couple decades of 'major version changes' to look at to learn from. I still can't say I agree with 100% of the decisions, but it's still progressing nicely.
> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc.
> Someone must be pulling a lot of hairs because of this.
PHP didn't learn from Python 3 BC fiasco, its governance makes such changes very difficult to be made.
Even as someone who supported it. Perhaps there was internal built up resentment.
Whatever it was it showed in their communication.
Very occasionally I have to communicate on a topic I think could see backlash based on internal views. I make an effort to communicate it as neurally as possible.
My org currently prefers a saccharin approach when there is controversy I can't stand that, but I prefer it to over the like it or lump it bristling with rage approach Python took.
PHP also cares a great deal about backwards compatibility. There are long deprecation phases before anything gets removed.
The RFC system also helps a lot in ensuring that changes to the language are well thought out to and discussed beforehand. The is not much change just for change's sake. Churn is kept to a minimal while still allowing the language to evolve.
> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
PHP upgrades are also good money for agencies. Got to earn that bread.
And to let out a dirty secret, for really hopeless projects there is the option to keep them on life-support by running them inside a docker container with an older PHP version. (Horrible but if that's what the customer wants, it's their risk.)
I have a private (non-internet) web-app that's still on PHP6.5; I like the new PHP features, but upgrading private code to conform to PHP 7 and 8 looks a lot like make-work. I wish it shipped with good upgrade tools.
[Edit] @darkwater (below) is correct; I meant PHP 5.6. PHP6 was some kind of abortion - I can't remember the story.
They replaced the MySQL plugin in version 7. All MySQL code was broken. I don't know, but I'd guess that most PHP sites were using MySQL as their database (the 'M' in 'LAMP' stands for MySQL).
Then I read a little closer, and realized I pretty much just had to add an "i" onto all the underlying mysql functions ("mysql_" to "mysqli_"), at least for the ones I was using commonly.
I'm still in the process of migrating that project, now on 7.4, to a modern Symfony framework, but I tested it out in 8.1 the other day, and it needed...1 change to work apparently perfectly.
I'm still going to need to do more thorough testing before I put production on 8.x, but with 7.x now unsupported, that has become a priority.
That said, I'm still surprised when I come in to codebases where people are still using hard-coded db function calls all over the place (mysql_* or mysqli_) I indicate that abstracting that away should be a priority. Even doing something as simple as "I want to log all the queries that I'm making for debug purposes" is essentially impossible when you have hundreds of individual calls to mysql_ embedded throughout the code. But... I've not come in to a codebase in the last... 4-5 years that does that, so either I've been lucky or that coding behavior is indeed becoming a thing of the past.
Not quite. Code that *wasn't* using either of the two modern APIs for MySQL was "broken".
They removed the oldest, jankiest of the three APIs for connecting to MySQL in php7.
MySQLi (literally, "MySQL Improved" extension) was introduced with PHP 5.0, in 2004.
PDO was introduced with PHP 5.1 in 2005.
The documentation started showing "soft deprecation" notices on mysql_* functions in 2012. It was already common practice to advise people to upgrade to either mysqli or PDO.
The old mysql extension was deprecated as of php5.5, in 2013.
The final shipped version with the mysql extension was 5.6, which was supported until 2018 - half a decade after the deprecation was added.
There is benefit if you have the project under test and can run the build with different php versions thought. Best in parallel so you have current, next and future. It perhaps becomes the norm since the yearly release cycle but always was a requirement when supporting different php versions.
More than a LTS release I'd prefer more PHP 8 releases than the five in 7.x, e.g. more until 8.8 or 8.9.
I'm doing this quite often as I maintain some code-bases that have backward compat down to PHP 5.3 as the baseline. So if you're looking for forward compatibility of your PHP 5.6 codebase to 7.x and 8.x (incl. 8.2), its not so much of work.
If you need an upgrade tool, have different PHP versions at hand and load each file on the CLI and PHP will show you the deprecation warnings. It then depends a bit on the code (each()/next()/reset() family undergone some changes if not removals in 8? so you have to replace with some different syntax) but most of the rest is only deprecation warnings that can be overcome with #attributes "annotations" that are just comments prior php 8.
tooling could be better especially if you're running from low versions, thought. but using php on the cli directly brings you quite far and on speed already for most things in my personal experience. git, find and xargs are your friends.
IIRC, the initial development was in the mid 2000s but it was abandoned several years later because they couldn't get Unicode support working correctly. By the time it was abandoned there was already a lot of material referencing it like books and conference talks. So when the PHP team decided to do a new major version most of the planned PHP 6 features were already added to 5.3 and 5.4 so they thought it best to just skip 6 to avoid confusion.