Strong disagree with this post. Semantic versioning means: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes.<p>The purpose is to enable APIs and build tools to work well, such as package manager project files that specify a version.<p>To answer the author's questions:<p>"When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?" I can tell it's a patch upgrade, so my team's projects can do this upgrade automatically, with tests of course. Also, I can look at the source git repo, or changelog, or equivalent.<p>"Can you tell me when version 1.2.1 was released?" Yes, by looking at the source git repo, or git tags, or changelog, or equivalent.<p>"What is your company/team's meaning behind a major, minor, and patch increment?" Semver specifies how to do this in the first paragraph of www.semver.org.<p>"Who decides when a new major version is released?" The person who is responsible for the API breaking change; depending on the team and goals, this person could be the developer, or project manager, or release manager, etc.<p>"What happens to the version where the manager or developer forgot to put together a change log?" We test for it in our git pre-commit hook and in our continuous integration. If your team isn't using those, or equivalents, then simply add a changelog and push a patch version.
No, don't do this. You're concerned about information loss, but without semver the consumer doesn't know if a major change occurred that would break their builds.<p>Software vendors and consumers do NOT want automatic major version bumps on Jan 1st. They DO want control over when a major version is released and when they update to it. Using 2022-06-11 as your version, do you hold all your major breaking changes for Jan 31st? That's impossible.<p>You get all those "Pros" by working within Semver and appending the date to the patch part: major.minor.patchyearmonthday<p>Edit: To support version parsers always expecting only 3 version numbers I removed the dashes in the example.
But you dont get the most important part: Will installing the 2022.05.03-37492af update break my build or not?<p>Semantic versioning is about compatibility and amount of changes, sort of. I know that going from 3.0.1 to 3.1.0 wont break the API.<p>Not once have I been asked when 3.0.1 was released - and if Im asked, I can look at the release posts, or anything else.<p>Cute idea, but appending a git commit hash to the end of a semantic version may be more useful than any of this.
Many of the disagreements in the comments seem to be overly focussed on versioning for <i>installable</i> software and dependencies (for example packages) where, I would agree, semantic versioning is still useful.<p>Not all software is a dependency though, and not all software is <i>installed</i> by end users. The approach in this article is fine for hosted apps, or anything that's at the top of the dependency chain.<p>EDIT: That said, this scheme is missing a <i>sortable</i> differentiator for multiple releases on a given date. This means there is no way to calculate the order of precedence between multiple releases on the same day, which is often important (though may not be in the author's specific case). I recently switched to using a hybrid version number which has elements of date based and semantic versioning (though not really "semantic" in the traditional sense):<p><pre><code> 2022.45.11+344.9c88541
2022 = Current year
45 = Release number in the current year
11 = Changes in this release (this is a count of Git commits on the release branch since the last tagged release)
</code></pre>
Metadata:<p><pre><code> 344 = Unique build number
9c88541 = Git hash
</code></pre>
This is completely automatically generated and each version is tagged automatically in the repo on deployment. So I never have to think about versioning at all.<p>I only use this for top-level applications (SaaS/hosted) which are continuously delivered (often with multiple deployments per day) and have no downstream dependancies.<p>I used to use Semver 2.0, so in my new hybrid scheme I wanted my version numbers to still have the same number of elements and still be sortable in a list with my older Semver 2 version numbers.<p>Given that my major versions never got anywhere close to 2022, this format gave me a nice seamless switchover, where order of all version numbers across both schemes was still maintained and my version numbers still had a consistent number of elements (important for my CI tooling):<p>Eg. versions, in order of most recent, still sortable across versioning format change:<p><pre><code> 2022.45.11+344.9c88541
2022.44.3+333.8b77462
2.1.0+303.1a65a73
2.0.3+297.3c878d2
</code></pre>
Or without metadata:<p><pre><code> 2022.45.11
2022.44.3
2.1.0
2.0.3</code></pre>
How does one release/run two parallel branches at once?<p>If I'm running version X.y, and (X+1).0 is released, but it's new and has a whole bunch of changes, I may not want to move to it right away. I can do that with SemVer since two parallel streams are possible.
Don’t have enough red pen to mark this, but how do you even sort versions chronologically if two or more are on the same date?<p>Also how do you tell between types of change? Major? Minor? Patch?
No, this is no good. Imagine trying to discuss the version with a colleague. We can all remember 2.1.3 but we can't remember the git short code and date.<p>If you're working on the project then you'll have a link to the repo or docs so it should be trivial to look up what changed based on the semVer change.
So your offering an alternative that has none of the benefits and a ton of problems outside of the original schema to solve the problem of “the developers don’t know how to use semantic versioning” and your proposed solution doesn't even solve the hypothetical problem you present in the introduction?<p>Yea, nah
"When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?"<p>Especially if you're using something like fzf that can easily search your command history, "every time someone has asked":<p><pre><code> git log <tag 1>..<tag 2> --pretty=oneline</code></pre>
I think this is ok for software with linear releases, for example closed-source SaaS applications. You can easily see the date of the release and compare 2 versions.<p>However a lot of software, especially in open source, does not follow linear releases. Let's say I use SemVer and I fix a bug in versions 1.2.0 and 2.3.0 of my library. I release Release 1.2.1 is created after 2.3.0, but I can easily immediately see it is not a continuation of 2.x branch. With GitDate, my bug fix will be called 2022.06.11-123abc, and it's hard to see that it's not a continuation of 2022.06.09-abc123 release, but an old 2021.11.12-def456 version.
This kind of sounds like "I choose semantic versioning but actually I didn't really need semantic versions, so now I just have a dated build number"<p>It's fine, but its not very useful in many different kind of situations. Like for instance managing firmware versions where you have a version 5 which is the last version compatible with a certain level of hardware and you need to hot fix it, while the most "modern" version is version 9.<p>But if you just keep releasing something like a website, then yeah, all you need is a build number, the date might be helpful, but most likely you don't care too much about that either.
If only he offered versions like <i>2021.03.22-rd31d336</i> instead of <i>2021.03.22.d31d336</i>, they would be semver-compatible while keeping all the benefits he is talking about.
We use this. Caveat: date is not the day of release if you are doing stuff in the “easy way” and aren’t full CD to prod. So your release on the 23rd could be something packaged the 21st<p>This basically doesn’t matter though, and is easy, and avoids most ordering questions as well that come with CI.<p>Highly recommend, and at least think semver is silly for versioning applications in general (libs are different of course)
<i>> Possible Cons:</i><p><i>> - Multiple builds on the same day? You would need access to the git repo to figure out which came first.</i><p><i>> - Customers now have visibility into the last time their software was updated.</i><p>- If corporations like Apple don't support it, the whole thing goes down the drain.<p>- I know this seems crazy, but I have met people that don't use Git for version control.
Date versioning is great. Just look at all the success of windows 95, 98, 2000 … oh wait. Let’s just give them cute names like xp, vista … oh wait. Everybody understands increasing version numbers. And semver provides more information at a glance than date+hash - that’s probably fine for nightly test builds but not for production releases.
I like this, I've already started versioning with the (2 digit lol) year as major version so 22.19.73 is the current year/release/build, but a standardized thing like this would be great. When versions gets old the version numbers start to add up you might as well use the year, ie Iphone 14, you might as well call it 22.
i’ll answer some questions from the article based on my own experience:<p>> When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?<p>patches mean small bug fixes or improvements that don’t break the api.<p>> Can you tell me when version 1.2.1 was released? Was it yesterday? Last year? Ten years ago?<p>for this we’ll have to check the repository. does it matter thou? if the package is stable then it doesn’t. it also depends on the platform. my golang projects rarely get updates. my javascript projects get updates once a week.<p>> What is your company/team's meaning behind a major, minor, and patch increment?<p>patch - small changes, no api changes<p>minor - medium changes, no api changes<p>major - big changes, api changes<p>> Who decides when a new major version is released? Is it a person? Maybe it's based on the size of an architectural change?<p>no, it’s if the api changes.<p>> What happens to the version where the manager or developer forgot to put together a change log?<p>we use git’s history for this.
I think a better idea might be the semver followed by the git short code. That way you get the benefit of API semantics plus a hash for build repeatability. The date is not that important.<p>And btw the word "inherit" in the first sentence should be "inherent."
Not all version storage mechanisms support non-numeric components. For example, Windows executables' <i>file version</i> values can only be up to four dotted number components whose values cannot exceed 65535.
SemVer allows for near-arbitrary version suffixes which can convey info like date and hash, so nothing should stop you from using <i>both</i> versioning conventions together.
Note that if you release something like 2021.x.x on an App Store you’ll never be able to revert back to a number like 3.x.x. So make sure that’s the direction you want to go.
It could be useful, I am working on a project now I think this would be a better fit. I don’t think it would replace semantic versioning for all projects though.
If the package manager for the system lacks sufficient information regarding any system component, that would seem grounds for switching to a different OS.