Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.68 as permitted sender)
To: internals@lists.php.net
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>
 <CAJHtznyB0oQVstisdOiqyM3uyJa8Hd7VM-RbE4nYNbLPg2Hpzw@mail.gmail.com>
Message-ID: <d00fa4ce-7bd3-c1aa-aaa7-82c1ab1ab1d1@gmail.com>
Date: Mon, 25 Jun 2018 21:40:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAJHtznyB0oQVstisdOiqyM3uyJa8Hd7VM-RbE4nYNbLPg2Hpzw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] PHP 8 next?
From: rowan.collins@gmail.com (Rowan Collins)

On 25/06/2018 19:54, Zeev Suraski wrote:
> 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.

IIRC, one of the arguments given at the time was "we don't know when 8.0 
will be, so we might have to wait for a long time". I never liked that 
argument, because it sounds like the arrival of a major release is 
entirely out of our hands, when in fact the opposite is true.

My argument then, as now, was that we should plan further ahead when 
each major release will be, and build up a list of things that will be 
in it. If anything, I think we should bump the major version number 
*more* often; if after 3 years we have 10 things like the too_few_args 
RFC, get them implemented, bump the version number, and move forward.

On reflection, I think maybe that phrasing reveals a difference in 
viewpoint: a lot of people talk about "a major release", which implies 
there's something big and exciting, rather than just a number. I think 
of it more like the marks on a ruler: centimetres are not more exciting 
than millimetres, but they are less frequent, and have some significance.


>> 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.


In an ideal world, there would be no reason *not* to upgrade to the next 
minor version, because you would know that your code ran on "7.x", so 
would just install the latest 7.x when it came out. I know reality is 
never quite that simple, but I think we can get pretty close with a bit 
of discipline and planning.

Regards,

-- 
Rowan Collins
[IMSoP]