> 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