Bye Bye Semantic Versioning, Say Hello to GitDate
https://taylorbrazelton.com/2022/06/06/2022-06-06-bye-bye-semantic-versioning-say-hello-to-gitdate/
There is inherit information loss when a developer implements Semantic Versioning.
Taken back a little by that statement? Well lets ask if it's true?
When was the last time you were able to easily tell someone the difference between version 1.2.1 and 1.2.3?
Can you tell me when
The last time when I was able to easily tell the difference was the moment I took a look at the changelog, that should exist alongside your releases.
The idea that you can see the date of a release in one glance is nice. However, how do you determine if a version update is a major update that involves a completely different way of implementing a function? Wouldn't you want to know before updating? Take an open-source library as an example...
Also, do end-users really care when their application was last updated? Sure, they want an up-to-date application that works but does it matter what version was released when?
First off, great response! Thank you for your ideas & thoughts. :)
Note: I primarily work with enterprise customers(fortune 500+) so my thoughts on these things are BIAS!
A change log should be made and exist alongside each release. However, with continuous integration and deployments happening more and more often, keeping track of these changes becomes more just tracking feature changes... Especially when you have multiple teams committing to a single repo during a single day.
If a function signature is changing then a deeper conversation should exist where a possible outcome is an adapter function so that the existing functions signature is not modified. Backwards compatibility should be baked into the codebase. To say it shouldn't be is to deny the existence of long lasting software. Microsoft.. SAP... a lot API's have version numbers for this reason. I just can't personally justify a "major" update without taking a look into replacing the poorly running/low functionality pieces of the existing software.
Why should an open source libraries public APIs change? Protected/Private APIs I can understand... but publicly used ones?
For example:
There is only one true way to open a file.. why would anyone need to modify that method? If you're adding like base64 decoding, I would encourage one to look into adding a new method to the File object called "file_obj.openAndDecodeBase64(path...)"
Enterprise customers care about updates a lot. Just like an update puts you back at the top of Apple/Android's list of recently updated apps.. an update for an enterprise customer usually means more functionality, faster performance, better experiences. I would be curious as to why wouldn't someone want the latest update for their app/software/website? Probably because of a "breaking" change ;) Last thing we want is customers who are afraid to update their software.
Thank you for clarifying.
Continuous integration and deployments definitely make it harder to keep a clear overview of which version has which features. And it gets more complicated as team size increases. I totally get that and I can see a use case there for this type of versioning.
Given the example of open source, there are numerous projects that pivot or change drastically over time because of new ideas and new use cases. This versioning scheme might not be useful in that case is what I was trying to say.
However, I understand where you're coming from and that there are more types of software out there. I'm not really into mobile development so I was not aware of the app store "recently updated" list but does it matter which version it is? I mean, as long as it is updated, and it is the latest release, it should not matter, right?
Also, I was not saying that updates are irrelevant. They bring more functionality, better performance and improved user experience in general. And both enterprises and customers want all of that. But again, does it matter which version number it is? I think it isn't. I think what matters is that it is the latest version, regardless of the version number scheme.
And for sure, the last thing we want is customers hesitating to update their software. Could not agree more on that.