On Tue, Jun 14, 2016 at 11:17 PM, Fleshgrinder <p...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
