Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102704
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c_L7S+EB8YxdNNpNZ7NhhYwCbwEw5_TSnSwUNN-zLVvCg@mail.gmail.com>
 <b4a9394a-184f-906a-0e34-c14cf8172666@gmail.com> <CA+kxMuQk_5KJT5RPK6B2+4whS1Wz4NTxLDAhXkc0uSurxPNLPw@mail.gmail.com>
 <CAESVnVrFsZCEbwTTs+ROF19nHh6=XN6dhHJqxVw5EKa5bK5ngA@mail.gmail.com>
 <c2b3a7b2-b4b6-db88-a7c7-5a08fed0d8a4@telia.com> <CAF+90c8tNO1SsMjGnW9tGPGHtY4kD07SNS-qC_LfkVXVsp0GUA@mail.gmail.com>
 <10e578d7-7a24-3ca0-ca0d-d5ed1a39dca3@telia.com> <80a8f588-05a3-48e5-bf40-bf1685b3105e@gmx.de>
 <CAF+90c-gOKrnHtLv1oJuHQ9QWxYjEZHwAzzaUL0c18x48=HezQ@mail.gmail.com>
 <bd79bc16-ff3d-1c9b-a775-9c50c422b8a2@gmx.de> <CAESVnVpHhKPBsTQgu=4u3UPC1oF_e6-iW9_njbq+09WTQb+Oqw@mail.gmail.com>
 <CAESVnVogxMdbdObdS2Kz-+WP5U=+VvzVXfr55Qy6iYNg=2Z-Wg@mail.gmail.com>
 <DM5PR0201MB35423A128EDAFE866C73B66EAC460@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <D197D623-17A5-4EB3-A578-93BF860AD68E@ez.no> <CADyq6sJDo_4jBx3dZ6eR7mS29-aEB7Ky3eta9st2VQDra23crA@mail.gmail.com>
 <CAOWwgpkC+-jvwN5VQwuvf6726e6cG4TD7hPpFcbKmtOXT7671w@mail.gmail.com>
 <CAJHtznxasnJE4mDsg7DYPBQZBCMkAKGafqj5MEMHMp03ye=RuQ@mail.gmail.com> <CAJd4=YYTP0caBhQda1HheiamHPtvO2XqXN4R=DgWF1iMdC7DeQ@mail.gmail.com>
In-Reply-To: <CAJd4=YYTP0caBhQda1HheiamHPtvO2XqXN4R=DgWF1iMdC7DeQ@mail.gmail.com>
Date: Tue, 10 Jul 2018 14:56:24 +0300
Message-ID: <CAJHtznybD1L5MnzhcNB_Kb0UPgag3zbrpOtr5zbfWCehx++R6w@mail.gmail.com>
To: mail@pmmaga.net
Cc: nicolas.grekas+php@gmail.com, Marco Pivetta <ocramius@gmail.com>, 
	=?UTF-8?B?QW5kcsOpIFIu?= <andre.romcke@ez.no>, Zeev Suraski <zeev@zend.com>, 
	Sara Golemon <pollita@php.net>, Internals <internals@lists.php.net>, nicolas.grekas@symfony.com
Content-Type: multipart/alternative; boundary="00000000000074f3310570a3d2f1"
Subject: Re: [PHP-DEV] [RFC] Typed Properties
From: vsuraski@gmail.com (Zeev Suraski)

--00000000000074f3310570a3d2f1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalh=C3=A3es <mail@pmmaga.net> wrot=
e:

> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski <vsuraski@gmail.com> wrote:
>
>> I've also given several examples - some of them arguably quite bigger th=
an
>> this proposal - where we sat on code for a very long time (multiple year=
s
>> even) in order for it to be included in a major version, and not a minor
>> one (phpng, JIT, FFI) even though technically they could go into the nex=
t
>> available minor.
>>
>
> Hi,
>
> I'm trying to understand this argument better but there is something I'm
> missing. Why would a feature like JIT (which would be transparent to the
> user AFAIK) need to wait for a major other than marketing reasons?
> Sorry in advance for the slightly off-topic question.
>

Major versions are in many respects "marketing" events.  They're an
indicator that big changes have happened in the language, big enough to
warrant a change in the major version.
It's a relatively recent evolution that we decided to only make it possible
to break compatibility in major versions (and it's a very positive
evolution, without a doubt), but either way - compatibility breakage has
never been the motivating factor behind a major release.  Major releases
enable compatibility breakage, not the other way around.
Major features have always gone into major releases (with one notable
exception - PHP 5.3, which many argue was a de-facto major release).

While 'marketing' always played a role in designating a certain version as
major - getting people more motivated to upgrade, bring positive vibes and
attention around the language, etc. (as was the case with 7.0) - since the
formal release process and the policy change to only allow compatibility
breakage in major versions - these compatibility breakages actually, to a
large degree, 'piggyback' on the major new features.  To make it more real
- what would the migration to PHP 7 look like if it was all about the
compatibility breakages, and not the performance boosts or for that matter
- scalar type hints?  Both of these (performance boosts and scalar type
hints) could easily go into 5.7 from a purely technical perspective.

Zeev

--00000000000074f3310570a3d2f1--