Hi, > -----Original Message----- > From: Stanislav Malyshev <[email protected]> > Sent: Tuesday, July 10, 2018 8:55 PM > To: Sara Golemon <[email protected]>; PHP internals <[email protected]> > Subject: Re: [PHP-DEV] On not rushing things at the last minute > > Hi! > > > I'm disappointed by the last minute kitchen-sink dump of RFCs being > > raised, rushed through discussion, and voted on with minimal periods. > > While I'm all for delivering useful features to end users, I don't > > want us to get in the habit of seeing months of quiet followed by > > weeks of chaos every year around this time. This isn't even new, > > though it seems like it's becoming more commonplace with the adoption > > of the yearly cadence. > > Yeah, I think it is natural (when deadline is closing in, people start to > rush in), but > not good. And I would feel for big features, like typed properties or friend > classes (without touching its merits) I think they should target 7.4. > > In the future, I think the expectation should be that if you have a large > improvement it should not be expected to land in the version that is already > in > the release cycle, even before feature freeze (especially if "before" is > measured > in mere days). Large features take time to figure out and stabilize, and that > should be the expectation. So you can write the RFC and open the vote > whenever you want and whenever the life allows you the time to do it, but the > expectation of where it lands should not be "immediately", especially for big > ones. > > What is "big" is subjective of course, but deep language level changes > (typing, > strictness, changing how major parts of language work, major language feature > like, I dunno, named arguments?) are big, and most deprecations or individual > function additions aren't. > I'm on the same page with Sara and Stas. There was a similar situation with 7.0 and the exception hierarchy changes. Even it was an alpha with a lot of other changes, there was a strong community demand and support. The feature was something completely new and different from the features establishing themselves over some years. That one however seemed dangerous for the stability. The decision was taken by the RFC vote, which had passed.
Some internal breaches are still allowed currently, while that is another matter in regard whether the user space functionality overwhelms. In some case, the internal stability concerning all the noncore stuff might be of more importance, sometimes it wouldn't. People might be busy and not get the RFC implementation earlier. Still, to keep the balance, IMHO we should have as a goal to have the feature freeze before the first alpha. Some nonintrusive RFC should be still applicable for the alpha or later, but a huge change should be excluded. Particularly with the typed properties patch - I'm sure Nikita and Bob would stand for the follow up fixes. Github screams, that the community support is huge. The idea was also brought and discussed earlier already. I personally have a bellyache that this patch is brought that late and has some internal breaches. However there's the demand and the consent wit hRMs. We should rethink this kind of situation for the future release schedules and limit RFC to the time before alpha, in general. Limiting this to before alpha has sufficiently more buffer than limiting it before beta. Regards Anatol
