On Tue, Aug 18, 2026 at 2:25 PM Weilin Du <[email protected]> wrote:
> Hi, > > I don't think making them all case-sensitive is better. Now, I understand > that, > most people in 2026 like stricter parsing. I indeed do either. > However, PHP is in a stage in it's lifecycle that it should take the BC > break into serious > consideration. In this proposal, we "trade" consistency with BC breaks, > and therefore I > want to keep the break effectively small. Changing three independent > functions' > behavior is surely worse than one, and since we've already keep the "bad" > habit of > processing case-insensitive extension names for decades, in my honest > opinion it is > more reasonable to only fix the one case-sensitive case. > Wearing my hat as a core developer, I object to this change. We *should* be making them case-sensitive - BC breaks are serious, but we have an established procedure for them, which is deprecation (e.g. in 8.7) and then removal in the next major version. The break here is also trivial to fix - convert the string to the right casing, or use something like `strtolower` if the name should be lowercase. > Considering branching: I don't want to get 8.6 RMs in trouble of these > small changes, > they surely doesn't qualifies as a urgent feature that can be merged after > the soft > feature freeze. Since I forget to make it clear: this should target 8.7 :) > > (Or, if 8.6 RMs want this to go into 8.6, please feel free to provide > feedbacks) > > Cheers to all! > > Weilin > Just to make it clear, since I wear another hat as the PHP 8.6 veteran release manager: my objection is as a normal developer, the view presented is my own and is unrelated to release management. -Daniel
