Hi Pierre,
De : Pierre Joye [mailto:pierre.php@gmail.com]
I do think we should. We are exactly at the point I was afraid to
reach with the unrealistic planning for 7. Engine is somehow stable
from an API changes point of view, so other can start to work on a
couple of key features. But it is too late. Let face it, some features
(like your RFC) will never make it post 7.0. We have to be realistic
about how things work now.
Agreed. It was announced 4 months from November but in such case, it is much too short. On the other side, the vote for the 7.0 timeline got 34 yes and 2 no. So, I assume people knew what they were doing. The RFC heavily insists on the need to keep the timeline as short as possible, so there probably was a reason, although it is not clearly explained.
My main concern is not about not being able to have my RFCs approved for the date, at least not directly. My concern is about the new features we'll announce. That's a major version. Everyone will talk about it. We have a communication window that won't open again before years. After the PHP 6 adventure, we'd better not fail this one ! So, what's the killer feature ? What do we put forward ? What do we base our communication on ? What do we want papers to talk about ? phpng ? That's great work, but low level, not much to sell except boring statistics ;), I may be wrong but, IMO, not much to explain to the average user: "Look, that's faster, do you want to know why ? Absolutely not, thank you". People want features, and we don't have so many to sell. Looking at the list of RFCs for 7.0, most are minor from a user's pov, or too low-level to communicate on.
Putting that in parallel with the recent activity on the list saddens me a bit, because several projects are coming, that can make a difference : STH (any version), of course, but also DbC, annotations, expectations. Named parameters would be great too if Nikita is OK. Parser extension API is a little low level for the average user but very interesting too. This is all recent, as Pierre explained, because most of these people were busy testing the core one month ago.
Now, if we stick to March 15, most of this won't go to 7.0 and some can even be lost forever. I hear some saying that, if it does not go to 7.0, it will be for 7.1. I disagree : a good part of this will be killed by BC breaks and the communication window will be closed by 7.1. 'PHP 7 features' will be announced everywhere. Definitely not the same for a minor version.
So, it's time to make a decision. My opinion is that, if we want to build a good feature list, we need more than 2-3 weeks. I would say roughly another 4 month : not too short, not too long.
Thoughts ?
Regards
François
Hi Pierre,
De : Pierre Joye [mailto:pierre.php@gmail.com]
I do think we should. We are exactly at the point I was afraid to
reach with the unrealistic planning for 7. Engine is somehow stable
from an API changes point of view, so other can start to work on a
couple of key features. But it is too late. Let face it, some features
(like your RFC) will never make it post 7.0. We have to be realistic
about how things work now.Agreed. It was announced 4 months from November but in such case, it is much too short. On the other side, the vote for the 7.0 timeline got 34 yes and 2 no. So, I assume people knew what they were doing. The RFC heavily insists on the need to keep the timeline as short as possible, so there probably was a reason, although it is not clearly explained.
My main concern is not about not being able to have my RFCs approved for the date, at least not directly. My concern is about the new features we'll announce. That's a major version. Everyone will talk about it. We have a communication window that won't open again before years. After the PHP 6 adventure, we'd better not fail this one ! So, what's the killer feature ? What do we put forward ? What do we base our communication on ? What do we want papers to talk about ? phpng ? That's great work, but low level, not much to sell except boring statistics ;), I may be wrong but, IMO, not much to explain to the average user: "Look, that's faster, do you want to know why ? Absolutely not, thank you". People want features, and we don't have so many to sell. Looking at the list of RFCs for 7.0, most are minor from a user's pov, or too low-level to communicate on.
Putting that in parallel with the recent activity on the list saddens me a bit, because several projects are coming, that can make a difference : STH (any version), of course, but also DbC, annotations, expectations. Named parameters would be great too if Nikita is OK. Parser extension API is a little low level for the average user but very interesting too. This is all recent, as Pierre explained, because most of these people were busy testing the core one month ago.
Now, if we stick to March 15, most of this won't go to 7.0 and some can even be lost forever. I hear some saying that, if it does not go to 7.0, it will be for 7.1. I disagree : a good part of this will be killed by BC breaks and the communication window will be closed by 7.1. 'PHP 7 features' will be announced everywhere. Definitely not the same for a minor version.
So, it's time to make a decision. My opinion is that, if we want to build a good feature list, we need more than 2-3 weeks. I would say roughly another 4 month : not too short, not too long.
Thoughts ?
Plenty of people voiced concern about the short time before feature
freeze, and people still voted for PHP 7 on that timeline. We didn't
magically have less time somehow. Features which don't make it in time
can shoot for 7.1 if they are backwards compatible, and if they aren't
they'll have to wait for PHP 8.
Those are my thoughts, anyway.