Re: BC breaking changes in PHP 8.1
| From: | Levi Morrison via internals | Date: | Wed, 22 Sep 2021 16:37:40 +0000 |
| Subject: | Re: BC breaking changes in PHP 8.1 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116137@lists.php.net to get a copy of this message | ||
> As somebody who's been contributing to and maintaining OSS libraries
> forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I
> can keep up with patches. I can keep up with new features. But BC breaks
> EVERY YEAR just creates churn. I've spent most of the past 18 months doing
> nothing but ensuring libraries work on new PHP versions. I then get users
> angry that they aren't getting new features; if I don't update to the
> latest PHP version, I get other users angry they can't use the library on
> the newer PHP version. And with new PHP versions every year... I
> essentially have to update every 2-3 years regardless, and will lose users
> if I don't do it every year.
I'm sorry you feel this way; this hasn't been my experience nor the
experience of many people which I interact with.
> Figure out what the BC breaks are going to be, and do them all at once.
> It's far easier for the ecosystem to adapt to a big drop of BC breaks every
> 3-5 years than it is every year.
We struggle to find consensus, and now you want us to find consensus
years in advance? Sorry, I don't think it's practical.
We can do better, though. I think we could commit to having no BC
breaks in the last minor of a major series e.g. no BC breaks in PHP
7.4. This requires us to agree 2 years in advance when we'll release
the next major. We could perhaps choose this for a fixed schedule,
e.g. we release a new major every X=5 years.
Anyway, I agree with an earlier statement that reverting resource to
object conversions at this stage is not feasible.