On 10/04/2023 10:48, Andreas Leathley wrote:
It would be interesting to know why some people are having such huge
problems upgrading their applications, as I think those would often be
good stories with something to learn in them. So to the original poster
or other people with big problems when upgrading, writing a blog article
detailing what happened would be helpful to evaluate if the PHP project
could improve something, or even why something broke.
Would it really be considered helpful? When I or others like jrf who see
the potential problems try to warn about these issues here on Internals,
our concerns are generally ignored, or it's considered that we don't
want to allow PHP to move forward, or that we're simply scaremongering.
We aren't against PHP moving forward; we're not advocating that changes
and improvements shouldn't be made.
We are saying that they shouldn't be purely technical discussions about
implementation here on Internals, but there should also be consideration
for the impact on existing userland code. All too many of the changes
made in 8.0, 8.1 and 8.2 had no impact assessment, no consideration of
how much effort might be required for users to make the necessary
changes in their code. Thankfully, I've started seeing some effort again
to include a risk analysis or impact assessment in some of the more
recent RFCs.
And many of those RFCs work on the assumption that all existing PHP
codebases are adequately covered by unit tests to identify the points
where changes need to be made, and written well enough that any
designated fix will always work. But in the real world, that is rarely
the case, particularly with older codebases. Too often the RFCs seems to
assume the happy path; with testing for edge cases in developers
applications after release.
> Nowadays there are even tools now like Rector that can help you
automatically
> upgrade your codebase - that is also a new value proposition.
Tools like rector can help, particularly for developers that are
specifically upgrading from one PHP version to another; and rector is
certainly a game-changer there in the same way that Composer changed the
way that we build applications and manage dependencies. Where rector is
less useful is if we need to maintain the same codebase across multiple
PHP versions, which is the case for many libraries, as well as some of
the tools that we use for developing and testing.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
