I couldn't find anything about runtime changes in the specification, only backward incompatible changes. If the code doesn't use any of the breaking changes from the language version semantic versioning doesn't care.
The polyfill does matter because json_validate is introduced in 8.3, therefor using it in Laravel 13 would make it a breaking change without the polyfill.
How does calendar versioning makes communicating compatibility boundaries more difficult?
The numbers only go up.
Semantic versioning doesn't care if it is 9 or 20 or 2026. You can skip numbers as long as they go up.
First you mention a major change only has to do with breaking changes, but in the end you mention it is also time based. So why can it not be also marketing driven, introducing a slew of new features or any other reason the developer thinks it warrants a major change?
The change I suggest is for every project that uses a yearly cycle. If they don't then it wouldn't make sense.
I think we’re circling a few different layers of the discussion.
On the runtime point: semantic versioning defines a major release as one that introduces incompatible changes. If a package raises its minimum PHP requirement, consumers running the previous version can no longer install or run it. That’s an incompatibility, even if the framework doesn’t use new language features directly. The breaking surface isn’t "does this code call a new function", it’s "can existing consumers continue using this version without changing their environment". In that sense, a runtime bump is unambiguously major under sem ver.
You’re right that polyfills matter when maintaining compatibility with older runtimes. But once the declared minimum version changes, the polyfill becomes irrelevant to versioning semantics - the incompatibility is the constraint itself.
On calendar versioning: you’re correct that sem ver doesn’t care whether the number is 9, 20, or 2026 - only that it increases. The difference isn’t about the size of the number, it’s about encoded meaning. With sem ver, MAJOR/MINOR/PATCH communicate compatibility expectations structurally. With pure calendar versioning such as 2027.03, that compatibility meaning has to be reintroduced via policy documentation. At that point, you’re effectively recreating sem ver rules on top of date-based identifiers.
Regarding cadence: there’s no contradiction between "major means breaking" and "majors are released yearly". The yearly schedule defines when breaking changes are consolidated. Sem ver defines how those breaking changes are signaled. One is release governance, the other is compatibility communication.
Could a project bump a major for marketing reasons? Absolutely - sem ver doesn’t prohibit that. But doing so weakens the informational value of the signal over time. The strength of something like Laravel is that its annual majors reliably correspond to real compatibility boundaries (mostly anyway), even if those changes are incremental rather than dramatic.
I actually think your suggestion makes sense for projects that are purely time-driven. But Laravel already operates as a hybrid: predictable annual majors combined with semantic compatibility guarantees. Switching to pure calendar identifiers wouldn’t meaningfully increase clarity - it would mostly change the aesthetics of the number.
I suspect we may just be optimising for different things: you’re valuing visible release age, while I’m valuing encoded compatibility boundaries. Both are reasonable priorities - they just solve different problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I couldn't find anything about runtime changes in the specification, only backward incompatible changes. If the code doesn't use any of the breaking changes from the language version semantic versioning doesn't care.
The polyfill does matter because
json_validateis introduced in 8.3, therefor using it in Laravel 13 would make it a breaking change without the polyfill.How does calendar versioning makes communicating compatibility boundaries more difficult?
The numbers only go up.
Semantic versioning doesn't care if it is 9 or 20 or 2026. You can skip numbers as long as they go up.
First you mention a major change only has to do with breaking changes, but in the end you mention it is also time based. So why can it not be also marketing driven, introducing a slew of new features or any other reason the developer thinks it warrants a major change?
The change I suggest is for every project that uses a yearly cycle. If they don't then it wouldn't make sense.
I think we’re circling a few different layers of the discussion.
On the runtime point: semantic versioning defines a major release as one that introduces incompatible changes. If a package raises its minimum PHP requirement, consumers running the previous version can no longer install or run it. That’s an incompatibility, even if the framework doesn’t use new language features directly. The breaking surface isn’t "does this code call a new function", it’s "can existing consumers continue using this version without changing their environment". In that sense, a runtime bump is unambiguously major under sem ver.
You’re right that polyfills matter when maintaining compatibility with older runtimes. But once the declared minimum version changes, the polyfill becomes irrelevant to versioning semantics - the incompatibility is the constraint itself.
On calendar versioning: you’re correct that sem ver doesn’t care whether the number is 9, 20, or 2026 - only that it increases. The difference isn’t about the size of the number, it’s about encoded meaning. With sem ver, MAJOR/MINOR/PATCH communicate compatibility expectations structurally. With pure calendar versioning such as 2027.03, that compatibility meaning has to be reintroduced via policy documentation. At that point, you’re effectively recreating sem ver rules on top of date-based identifiers.
Regarding cadence: there’s no contradiction between "major means breaking" and "majors are released yearly". The yearly schedule defines when breaking changes are consolidated. Sem ver defines how those breaking changes are signaled. One is release governance, the other is compatibility communication.
Could a project bump a major for marketing reasons? Absolutely - sem ver doesn’t prohibit that. But doing so weakens the informational value of the signal over time. The strength of something like Laravel is that its annual majors reliably correspond to real compatibility boundaries (mostly anyway), even if those changes are incremental rather than dramatic.
I actually think your suggestion makes sense for projects that are purely time-driven. But Laravel already operates as a hybrid: predictable annual majors combined with semantic compatibility guarantees. Switching to pure calendar identifiers wouldn’t meaningfully increase clarity - it would mostly change the aesthetics of the number.
I suspect we may just be optimising for different things: you’re valuing visible release age, while I’m valuing encoded compatibility boundaries. Both are reasonable priorities - they just solve different problems.