> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to