Here I go again! I couldn't find it but I remember I did a rant about Laravel needing to pick date formatted versioning instead of semantic versioning when Laravel 12 was announced.
The reason I'm writing this is because Livewire can announce a release compatible with an unreleased major version.
Lets dive in.
Semantic versioning
The main goal of semantic versioning is to make the dependency management predictable.
It uses three sets of numbers divided by a dot. The context of the numbers from left to right is major, minor and patch.
A major number change must happen when there are backward incompatible changes. But it can also happen when multiple features and or changes are introduced.
The Laravel situation
From the commits on Github and a blog on Lavavel News The biggest change is the optional use of attributes.
While they added quite a few attributes, does this really warrant a major update?
You could argue raising the minimum required PHP version, 8.2 to 8.3, is cause for a major change.
When I look for an 8.3 feature like json_validate I see that they are are using the Symfony polyfill in version 12. So there is no need to raise the major version.
Why do they keep on using arbitrary semantic versioning?
Because it is the convention in the community?
There are no side effects if they are using the number parts as year, month and day. They could even add the time to the patch part in case they need to create multiple releases on a single day.
This means releases with backwards incompatible changes can only happen once a year.
I like the explicitness of the date versioning over the arbitrary number, you can actually see how old the version in the application is. This could open some eyes.
Are we doing semantic versioning wrong the whole time?
In the beginning of a project it is likely that backwards incompatible versions can be happen closer to each other. So in that stage the arbitrary numbering is preferred.
When the project is matured I think the step to date/calendar versioning should be taken.
PS: the post moved from rant to realization. But I kept the title for the views.
Top comments (3)
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.