Semantic Version vs Date Versions
In recent times I noticed a few projects moving to a date based versioning from a semantic versioning, any project is free to choose the versioning system that it prefer, though this has impact on the message that this transmits to the user, before going through this let's do a quick recap of what semantic version means, got from: https://semver.org/ (where you can read of all the details)
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
Given this simple information, as a user of a library and/or application, as soon as I see a new version of a software I can quickly determine if is a no effort update, or I may expect that it requires some effort from my side (which it may be minimal or absent for my specific use case), having this information can give me a hint on engaging with the update, or delay it because the current situation/environment does not give me the space to handle the incompatibilities.
Now checking the new versioning systems based on dates, there are a few formats I saw in the wild:
- YYYY.MM for example 2024.05
- YYYY.MM.DD for example 2024.05.04
- YY.MM for example 24.05
- YY.MM.DD for example 24.05.04
These are often technically compatible with the semantic version, as the software that parse versions can read and determinate what is the more recent version in the same way of the semantic version, but they loose all the meaning of the semantic version, or better if you still want to keep the meaning it gets a bit messy as:
- You cannot do two patch releases in the same day, which is not common, but it may happen in some extreme case
- You are expected to not do two minor in the same month, again not too common but with dev cycles of 4 weeks it may happen and may result to ship a new feature in a patch release
- Braking changes are allowed only once a year which again in some cases is normal but is a limit
- If you do a patch release the first of the month, it does not look like a patch release but like a minor
- If you do a patch release/minor release the third day of the year (yeah holidays and hangover) it looks like a major that expect breaking changes
All this points (and for sure there are more) make it clear that assimilate the date and semantic version is not really compatible, and even if the version format it looks like the same, it is not, especially when the major.minor.patch semantic is embedded in automatic tools, that cannot really know that 2025.01.03 is an emergency patch release done to fix a critical issue, and the 2024.06.20 is a breaking change release that should not be updated from 2024.06.10.
Also using the format YY.MM.DD is almost impossible to guess the difference from a normal semantic version and a date, even for humans, where instead the full date YYYY.MM.DD can be guessed more easily because is not too common as today to have a semantic version that go over the 2000 majors.
Another related issues is also that the projects that ship date related version need to define somewhere else the compatibility criteria, so as a user I need to inform myself on the specific versioning system of the specific project, that is a usability issues compared to a relatively standard semantic versioning.
Sometimes I see argument against the use of semantic version from software like desktop applications or mobile apps, because UI incompatibilities are not perceived in the same way that software developers perceived library incompatibility, "User just need to re-learn to use the new version of the app". Instead, would be really cool having also in the desktop/mobile applications the semantic meaning:
- patch just fix a bug of something not working well in the UI or some unexpected error
- minor just add some new functionality or some new menu buttons
- major ship some new UI redesign and break some compatibility with external files/tools/services
This may give a hint to me if update or not the application before running some time sensitive operation, a new UI may slow me down.
Just to close this point I do repeat that each project is free to define is versioning system, see project like the Linux kernel or the gnome project that did not use (and still not exactly use) semantic versioning, just keep in mind what your (automated) user expect to see and understand better.
