Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com>
Date: Wed, 15 Jun 2016 17:41:47 +0700
Message-ID: <CAEZPtU6PonqQcT5sQf1FUd-Vwp-qcZ5r0jzL-Cdn3r3=wpLJDA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Dmitry Stogov <dmitry@zend.com>, Rowan Collins <rowan.collins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Jun 14, 2016 at 11:17 PM, Fleshgrinder <php@fleshgrinder.com> 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.
>
> 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.

This is the plan. We did not manage to stick major releases in the
release process RFC as it was already very hard to get a compromise.

As I think it is a bit too early to plan 8.0, we should definitively
start to think about what we want/would like to focus. It can be like
7.0, no major breakages but on spot improvements that are not possible
in 7.x

About the BC breaks, the RFCs do not define them clearly. It is a
complex topic. Bugs fixes can be seen as BC breaks (old enough bugs
become features). However new warninngs (except fatal) are not
considered BC breaks. Behavioirs changes are and that's why some fixes
or improvements require a RFC. I understand that a RFC allowing to
break BC is not good thing from a policy point of view, but as far as
I can tell, the ones we chosen so far were more than welcome by the
communities, which is a good sign about our handling of BC breaks.

I also understand the needs to change, update, optimize or clean our
edge cases to open the path to JIT and the likes. However I would be
very careful about that, and Dmitry and the team are very careful. I
also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the BC breaks in
8.0 and prepare our users using 7.x.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org