On Tue, Jul 10, 2018 at 12:35 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 10.07.2018 at 09:36, Nikita Popov wrote: > > > To make sure there are no unreasonable expectations involved in this > > decision: If this feature will not go into PHP 7.3, then it will in all > > likelihood go into PHP 7.4 instead. I think I can safely say not just on > > behalf on Bob and myself, but also on behalf of the wider PHP community, > > that we are not willing to sit on this feature for 2.5~3 years until a > > hypothetical PHP 8, even though it is essentially ready *now*. Of course, > > this is not my decision to make, but as Sara put it, that's the writing > on > > the wall. By deciding not to include this in PHP 7.3, we are essentially > > making an implicit decision that PHP 7.4 is going to be a relatively > > ordinary feature release rather than a deprecation-only one. (Which is > fine > > by me really, I don't like the idea of a release that's all stick and no > > carrot.) > > > > Finally, given the current situation where we have a whopping five (!!) > > RFCs with votes ending the day before feature freeze, I'd say postponing > > the schedule is a good idea even without any consideration to typed > > properties. Just landing something like the comparison overloading RFC on > > the day of feature freeze is not going to be pretty. We are quite > obviously > > rushing things right now, and I don't think keeping to some otherwise > > arbitrary date is worth that. > > Good point! Thus, I suggest to put in *one* additional alpha (i.e. > postponing feature freeze by two weeks to 2018-07-31) in any case, have > the vote on “Typed Properties” starting soon with explicit options which > version these should be merged into, and if there will be an option to > target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to > insert yet an additional alpha5. > That sounds like a very reasonable approach to me. Anyhow, I strongly suggest to amend our voting and release rules to > avoid such situations in the future. Ending any vote one day or a few > days before feature freeze should simply not be allowed (unless the RFC > targets another version). And there should be clear rules which > circumstances warrant or allow to postpone feature freeze, and who's > decision that is. > Ugh yes. A hard rule that no new RFCs targeting the branch can be submitted 4 or 5 weeks before the feature freeze would be reasonable and would avoid this mess in the future. Especially if could get an announcement about the approaching "RFC freeze" a month or so in advance. Nikita
