On Saturday, 9 March 2024 at 19:44, Jim Winstead <j...@trainedmonkey.com> wrote:
> This may be a dumb question, but what's the process for determining whether > the next significant release of PHP will be a minor version or a major > version? If the adherence to semantic versioning is meant to be strict, it > doesn't make any sense to vote on what version something like belongs to, > because then you're saying that whether a BC break is significant enough to > merit an increase to the major version is up for vote. We don't follow semver and never have. There have been BC breaks in every single minor version of PHP since PHP 4. The general attitude is that minor BC breaks are OK in minor versions and must be clearly documented. I will also mention that most programming languages to not follow semver and instead have a set number of versions a deprecated feature exists before being removed, Python being the most famous example. There is no process on how or when a major version should occur and AFAIK it has always been a core developper choice when to push for a version to be a major. Me, and some other members of the Foundation, currently don't see the immediate benefit of having a major version soon. For me, what would cause the roll-over to PHP 9 is converting streams from resources to objects as this not only has a relatively large impact on userland (that we can talk about how to mitigate) but also impacts every single PHP extension that uses streams in some capacity. I also have another selfish reason for wanting to delay PHP 9 for at least another minor version as I still have a large language semantic RFC (in the vein of the container/offset one I just posed) I want to do, which I'm not sure I'll have ready in time before the feature freeze of PHP 8.4. Best regards, Gina P. Banyard
