Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119879
Message-ID: <85333a00-85a4-d9cd-b108-8f1a98347f88@demon-angel.eu>
Date: Mon, 10 Apr 2023 22:42:45 +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>
 <CAL0xaBF36A3XUADe7DZGyDu5rmSN77o9rku4F0ApsCNHLchkdg@mail.gmail.com>
In-Reply-To: <CAL0xaBF36A3XUADe7DZGyDu5rmSN77o9rku4F0ApsCNHLchkdg@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 19:04, Arvids Godjuks wrote:
> I also want to add that PHP is purely developed by open-source contributor
> efforts who are limited in their numbers and not a lot of them are getting
> compensated for it (exceptions being specific people working for companies
> who have a vested interest in PHP development like JetBrains, hosting
> giants and some others. And now PHP Foundation is there to help people get
> paid for their crucial roles in PHP project and their dedicated time).

Yes we know, and we're very grateful; but that doesn't mean we should be 
unquestioningly grateful!

And some of us are also open-source contributors, not getting 
compensated for it. We understand; and just as I try to take a 
professional approach to my OS contributions, and assess the impact of 
any change that may affect bc, I hope that PHP Internals does the same, 
but I don't often see that. So am I expected to stay silent when I see 
potential problems with bc breaks because I should just be grateful?


> You also have a world on your hands that is changing - everywhere you look
> things are going for a more typed approach. That's what developers of today
> expect. That's the reality of how modern libraries are developed and old
> libraries have been actively migrating to strict type code bases. This code
> quality improvement absolutely takes a huge load off those developers'
> shoulders. I'm seeing libraries out there now that basically require PHP
> 8.1 as a minimum because Enums are all the rage and almost half the
> libraries I use have introduced them in their code in the latest versions
> and authors just flat-out tell you "use the older version of the lib or
> update your project"  (and I have at least 7 of them in my code already and
> that project will never run on anything lower than 8.2). Some of the
> biggest libraries out there have fully adopted SemVer and will bump the
> minimal PHP version quite aggressively. And will tell you to pay for
> commercial support or deal with it on your own. And now the Union types are
> coming and I expect that to get adopted at a rapid pace by everyone and
> their dog.

Yes it is changing, but at different speeds in different companies. 
Changes aren't being adopted at that rapid pace by everyone and their 
dog, that's the reality.


> Just as owning your own house means you need to do the upkeep on a yearly
> basis or it will become a mess, the same is with code and not maintaining
> it - eventually, the roof will cave in and the costs of fixing it all will
> skyrocket. And, frankly, this is the feeling I get from a lot of this
> thread - the roof has collapsed and people are put into impossible
> positions of "no, you can't have the time or resources to update the
> project to the new PHP version, here are 20 KPI's for the next 3 months you
> need to hit". The codebase was run on a credit of "this will be fixed down
> the line". Well, the debt collectors now what their debt, their late fees
> and lawyers want their slice of the pie.

Do you think we're unaware of that! But you're suggesting that anybody 
that isn't using the latest shiny release should be treated as though 
they don't exist. They're not your problem, so forget about them. Many 
of those developers would love to upgrade to the latest shiny release, 
but that isn't always an option every November; that run-up to Christmas 
can often be the busiest time of year for those developers, the time 
when they are least in a position to go through an upgrade.

Telling them that the debt collectors and lawyers are here isn't going 
to help them when the people that pay them so they can eat and have a 
roof over their heads and care for their families is a slap in the face 
to them when they are torn between business demands and wanting to do 
technical upgrades.


And the attitude of some here on PHP Internals that we should just 
ignore those who can't develop in greenfield environments using the 
latest shiny, or that it should just be a simple upgrade step from last 
version to current release... that's the equivalent of having unit tests 
that only test the happy path.


-- 
Mark Baker