Hi Pedro, Le 07/06/2017 à 20:23, Pedro Magalhães a écrit :
I will not change the target version now during the voting phase. Also because it wouldn't make sense to vote for a feature for 8.0 yet. If the RFC is rejected and the sentiment is that most people would agree with the change but not with the timing, I will propose it again when RFCs for 8.0 are relevant.
I am sorry you take it this way. Voting today on a feature for 8.0 wouldn't be ridiculous and it would make me change my vote, as most others. Instead of nonsense, it would be a sign of maturity for the PHP project. It would be great, IMO, to open a 'Approved for 8.0' section on the RFC page now, and your RFC could proudly be the 1st one to enter it.
This would prove, IMO again, that we are finally able to think more long term than we did in the past. The most interesting proposals for 7.0 were rejected before it was too late to introduce such disruptive changes. They should have been prepared a long time before, introducing a compatibility path, so that people could prepare their code. This was also one of the reasons for the failure of PHP 6.
So, advertising a future BC break months before a release perfectly makes sense. The only risk would be to forget it but, by creating a specific section on the RFC page, we ensure it won't. In theory, it should even work this way : gather proposals, vote, feature freeze, implements PRs, merge them, and, only at this time, start publishing alpha, beta, RC, final. We accept changes after publishing alpha because most people wake up too late. So, I encourage you again to initiate a much more mature way of planning the next major version !
Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
