Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119862
Message-ID: <a988970e-d467-3af1-705d-b41a3ebb7a2b@demon-angel.eu>
Date: Mon, 10 Apr 2023 17:34:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
To: internals@lists.php.net
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAGBsUrcQWKc+JD2adprcgdqNAKr==McFeoYO3WF3pR2qxgon2g@mail.gmail.com>
 <CAMXcktN64EsoErjbFzdWe+qzM5RVYNR98WO8xcLOYxeYCK=NiA@mail.gmail.com>
 <CADK1yXJMgSrjCahW2_G-C=ye=mBiuWtQAKyJrbFc-W4ODL6fZw@mail.gmail.com>
 <CAGBsUrd=X6d8eZsSjaz+hQYLTCPCHPExhsawWhr8BWD=prEb1Q@mail.gmail.com>
 <CADK1yXK85kUV2D5tcs2eCbFcEnDxXiGsm2qrhkxjAwpMZz7sUg@mail.gmail.com>
 <8b20a236-c4c4-9b61-43f1-ff6145752c75@gmx.net>
Content-Language: nl
In-Reply-To: <8b20a236-c4c4-9b61-43f1-ff6145752c75@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Future stability of PHP?
From: mark@demon-angel.eu (Mark Baker)

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