Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102434
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c8S3UK3xakJQ4eD1mCMvBAdms2_d5aDd0oOZHfi67Mn9Q@mail.gmail.com>
 <CAESVnVqKqLDcbrTwzSD2qms32kF3FROa6XGXp9UEgp2MLjDvPw@mail.gmail.com>
 <DM5PR0201MB35423C070BADA25899A12E1EAC740@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NoB-WvTZ=tEqeMMOdt0vDxPLqe-_Ab93xqeKp1GXYjfew@mail.gmail.com>
 <DM5PR0201MB3542CDDEC128637665333A61AC4B0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NrWt0APfRKaDc_m0WXT=i2+qRLZkDutVofHfrsk4dm3_w@mail.gmail.com>
 <4CD11D3A-D799-46CF-9DD0-E34552FB15CD@gmail.com> <4552e1c3-b538-17ab-95fd-708dfa4f0d5a@lange.demon.co.uk>
In-Reply-To: <4552e1c3-b538-17ab-95fd-708dfa4f0d5a@lange.demon.co.uk>
Date: Mon, 25 Jun 2018 13:39:13 -0400
Message-ID: <CAPKYkKzY2V11d0GaeZfuUm91K2fskHgxyYJtXA4AsZn-Lv7gGw@mail.gmail.com>
To: Mark Baker <mark@lange.demon.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d25e78056f7adc45"
Subject: Re: [PHP-DEV] PHP 8 next?
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000d25e78056f7adc45
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 1:16 PM Mark Baker <mark@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
chasepeeler@gmail.com

--000000000000d25e78056f7adc45--