Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119877
Message-ID: <1915e90c-0a9d-de26-c87c-9c99908154cf@demon-angel.eu>
Date: Mon, 10 Apr 2023 22:21:05 +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
Content-Language: nl
To: internals@lists.php.net
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
In-Reply-To: <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
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 18:17, Pierre Joye wrote:
> I understand agency work, managers pushing new features instead of a
> cleaning some legacy.
>
> however years of ignoring deprecation notices (very few were introduced
> right before 8.0).
>
> Most of them could have been fixed within a couple of hours in any code
> base, if they had tests.

> I would suggest, very very nicely, to review and rethink the development
> flows of these projects instead of asking php to freeze.

We're NOT asking PHP to freeze!

We're asking for proper analysis of the effects of these changes on end 
users, and proper consideration of the time that it will take for 
end-users to upgrade... and the answer to that is NOT "within a couple 
of hours". Call it unnecesary overhead if you will, but many tech teams 
have process flows for their work that don't simply entail "run rector 
on your codebase and deploy". Even just the admin overheads of raising a 
ticket for the change, creating a Merge Request, Peer Review, etc can 
take a few hours of time in many teams. And that's before making the 
assumption that all older code has a good test suite, and CI pipeline... 
if it has, then it's probably code that's being updated regularly 
anyway, by developers that do try to keep everything up-to-date.

Nor are end-user developers the only people that are affected. End-user 
developers typically have the luxury of writing their code for a single 
version of PHP, so upgrading the version is a step from one version to 
the next. Library writers don't have that luxury: their codebase 
normally has to work with a range of PHP versions including the latest 
release; and any fixes that are made for the latest release still have 
to work with older PHP versions, which can take significantly more 
effort to maintain.


-- 
Mark Baker