Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102437
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.178 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>
 <CAPKYkKzY2V11d0GaeZfuUm91K2fskHgxyYJtXA4AsZn-Lv7gGw@mail.gmail.com>
In-Reply-To: <CAPKYkKzY2V11d0GaeZfuUm91K2fskHgxyYJtXA4AsZn-Lv7gGw@mail.gmail.com>
Date: Mon, 25 Jun 2018 21:54:43 +0300
Message-ID: <CAJHtznyB0oQVstisdOiqyM3uyJa8Hd7VM-RbE4nYNbLPg2Hpzw@mail.gmail.com>
To: chasepeeler@gmail.com
Cc: mark@lange.demon.co.uk, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d9ac38056f7bea2f"
Subject: Re: [PHP-DEV] PHP 8 next?
From: vsuraski@gmail.com (Zeev Suraski)

--000000000000d9ac38056f7bea2f
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> 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.
>

I agree.  It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.


> 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.
>
> Fair enough, and I think there'll likely be a lot of folks that would see
no point in going through such a 7.4.  However, I think that folks working
in more agile companies, or even developers that want to get a head start
on preparing for 8.0 - will find value in such a release.  TBH, the vast
majority of users don't upgrade to our minor versions even when they bring
new features and capabilities.

Zeev

--000000000000d9ac38056f7bea2f--