Q&A highlight
Posted27 days ago
Key Takeaways
Anything fancier doesn't really tell you exactly what features changed when, so a table in the documentation spelled that out for each version.
Although knowing the date is nice, especially to indicate an application is dead end. But I rarely need that. When I first download it, and when I wonder ... hmm is this product ever going to be updated.
I am not sure what the value of putting the year in the version.
For my own home projects, and work pre-release, I always list the build date on the screen. Saved me more than a little frustration.
You could combine them. Either Year.Major.Minor.Patch, or the other way around. But like I said before not sure of the value.
I suppose it is finding the "perfect balance" for human reading and customer support.
If you are actually going to (attempt to) support multiple releases, semantic major.minor.patch is very useful.
If you're really just going to support only the latest, semantic versioning is probably not so helpful, year.version is easy to figure out chronological differences with.
githash as the only version identifier is a sign that you don't intend to help users track versions. This could be the right choice if you want to release something without expectations of use.
For libraries and even the internal version number of a public product like an OS release where developers still want to say.
if os.version > x:
standard semantic versioning.
On the other hand, unlike products, libraries still make sense to version semantically as it is technical information for the users of those libraries that clearly communicates breaking changes.
Year.version might be better for marketing though.
Who’s your user base?
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.