On Wed, Sep 22, 2021 at 9:39 AM Calvin Buckley <cal...@cmpct.info> wrote:
> On Sep 22, 2021, at 11:24 AM, Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > > 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. > > > > 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. > > There’s merit to spacing it out - I doubt anyone wants another PHP 7 flag > day again. > > (Ask the Python people how they feel about moving all the breaking changes > to a single release…) > I can tell you now a lot of us OSS maintainers would prefer it to yearly updates. It might be a good idea not to assume, and instead actually do some scientific polling of users and ecosystem library/framework maintainers. Based on my conversations with other maintainers in the ecosystem, my experience is not isolated by any means. On top of that, I get to analyze the annual Zend user surveys, and the number one reason for people being on older PHP versions (and > 50% of respondents are, EVERY YEAR) is the cost of upgrading. Clearly, there's a perception that something is broken with the current approach, and internals is ignoring it. BTW, another good possibility, recommended by somebody responding to a twitter thread I started around this issue: work with RectorPHP to provide a ruleset for each minor release, to ease upgrades. It's far easier than having to read through an UPGRADING guide and having to figure it out for yourself. I'd argue these should be in place as soon as a beta is ready. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
