Re: Is the "No BC Breaks in Minor Releases" policy enforceable?

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.