Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.120 as permitted sender)
To: <internals@lists.php.net>, Rowan Collins <rowan.collins@gmail.com>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
Message-ID: <43542f0a-37b9-5eb8-c6d2-e502b95fe7e5@zend.com>
Date: Tue, 14 Jun 2016 20:57:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2016 17:57:43.8243 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1784
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: dmitry@zend.com (Dmitry Stogov)



On 06/14/2016 07:17 PM, Fleshgrinder wrote:
> On 6/14/2016 12:43 PM, Dmitry Stogov wrote:
>> Hi,
>>
>> Just take into account, that 7.0 was released more than after 10
>> years of php-5 life, and of course we don't have any plans or goal
>> for 8.0 yet.
>>
>> Waiting another 10 years for fixing inconsistencies, that we "missed"
>> in 7.0, would limit our progress on bytecode and VM optimizations
>> targeted to 7.1 and future progress in next minor versions.
>>
> Isn't that just an excuse to creep in breaking changes? We all
> understand the goal here and we all are in favor of it. The problem is
> that it still is a breaking change. It would be better to elevate the
> E_INFO to an E_WARNING and create that PHP-8.0 branch with the actual
> error and start planning the 8.0 release.
In my opinion, the BC break is really minor (to be included into 7.1).
It may affect only buggy code, that can be fixed by removing unused 
arguments.
This was repeated here for few times, and for now, the majority of 
voters are agree.
I have nothing to add.

>
> PHP 5.4 was already like a PHP 6.0, it was simply not called that way.
> Why not learn from past mistakes and improve upon them?
>
> Having a release cycle that is faster than the current one would help
> users and companies. People could plan according to it. People would
> know what to expect and it would most certainly make it easier for all
> of use to plan and align.
>

Better planning might be great...
Anyone may propose an RFC to start 8.0 development with plan, goals, 
estimations, release schedule, etc.

Thanks. Dmitry.