Hi Dan and Tim,
> The RFC author could just say that yes votes for deprecation and > eventual removal will be added together, with the timescale being a > preference vote. > Thank you, Dan, for the clarification, that was indeed what I meant. I'll also make this clear in the RFC, unfortunately I forgot it so far. … the following: I wanted to know if > "Deprecate in 8.x + not remove in 9.0, but only remove in 10.x or 11.x" Yes, this is also a possible choice. Actually, I'm sure there were multiple things deprecated in 5.x, which only got removed in PHP 8.0. At least this is what I remember. :) The reason why I still opted for the possibility of "deprecate in 9.0 and remove in 10.0", because in my opinion this choice would suit better some of the most widespread functionalities. Not deprecating them formally straightaway in 8.x versions, but only providing a suggested alternative instead of them, would first of all buy some time for people who don't yet want to deal with this problem at all, but still allow them to voluntarily migrate when they are ready without nagging them. Then they had a relatively long time period when we would warn them a bit louder. A full major release cycle should be more than enough time to perform the migration. With all that said, personally I don't think any of the affected functionalities (maybe with the exception of only one of them) warrant such a long phasing out period. Regards, Máté
