On Mon, Jun 25, 2018 at 1:16 PM Mark Baker <m...@lange.demon.co.uk> wrote:
> On 24/06/2018 18:23, Rowan Collins wrote: > > I've argued before that there should be a roadmap and a cycle for major > releases, and if not, then some agreement on what triggers one, but we've > so far not managed to agree either. > > I do believe a road map and a cycle is a good idea. I'm hearing some > complaints from on the ground that releases are currently too frequent, > making it difficult for larger organisations to keep up when they have > to retest all their own apps/libraries/plugins with the new versions. > > A fixed cycle and schedule could help plan for change. > > -- > Mark Baker > > _________ > |. \ \-3 > |_J_/ PHP | > || | __ | > || |m| |m| > > I LOVE PHP > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'd like to put in my two cents as someone in userland that isn't really involved with the development lifecycle of PHP. I'm aware that my opinions might not be shared by others, so I'm not claiming to speak for anyone else. I've always viewed major releases as "This has MAJOR changes to the backbone of PHP" - Old code is more likely to break during a major update, but, doesn't have too. Minor releases, on the other hand, are more about fixing the bigger bugs and introducing some new functionality, but nothing ground-breaking. While still possible, the chances of old code breaking should be pretty small. Changing that third number is just about security and bug fixes. Let me expand on two of those points: 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was released, because we had already made major updates to upgrade to 7.0, and 7.1 introduced a few things that would have broken our code - we didn't have time to fix those by that point. "Throw on passing too few function arguments" would actually break more stuff in our legacy code than all of the 7.0 changes combined. 2.) JIT, FFI, and Async are things I'd consider "major changes to the backbone of PHP" just like the overhauled engine in PHP 7. Finally, I personally see the idea of a deprecation only release to be kind of silly. I don't work for a software company. It's tough enough for me to make a case for upgrading using the "increase performance" and "new features" argument. There is no way I'd get the go-ahead to do an upgrade that would just make additional features deprecated. It would be a better use of my time to look for and fix the deprecated features as part of the 8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some of the new 8.0 features that aren't really dependent on the major things like JIT, async, etc., as part of the 7.4 release. -- -- Chase chasepee...@gmail.com
