On Fri, Aug 9, 2019 at 4:30 PM Zeev Suraski <z...@php.net> wrote: > In the spirit of my response to Bob, I added a new FAQ: "How does this > differ from Nikita's Editions idea?" > > """Related to rollout - the Editions approach doesn't allow for just two dialects - but any number of dialects. We could have a PHP2020 dialect, along with a PHP2022 dialect and a PHP2027 dialect. If we keep them all - this may actually increase our maintenance complexity."""
I don't think we would keep them all. We could set a sunset cycle for dialects similar to branch support cycles. PHP2020 comes out and we support that along with PHP1996. Two years later, we introduce PHP2022 and we continue to support 2020 and 1996. When PHP2024 comes out, we drop PHP1996. When PHP 2026 comes out, we drop PHP2020, etc.... This does introduce a point where legacy apps must fix their code or simply not upgrade, but it also provides a path to upgrade to latest support version, then migrate files one at a time to that version's latest, allowing an update to latest-latest. This is significantly better than the current state of syntax BC breaks which requires all updates to occur WITH the upgrade. Meanwhile, we have a little more work (work you and Niki are both suggesting we take on already), but with a bounded cap on how long we carry complications around. -Sara
