7 ms·

Bye Bye Semantic Versioning, Say Hello to GitDate

32 points by jeremylevy 4y ago

rr808 4y ago
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.
blowski 4y ago
Isn’t the “semantic” part of semantic versioning that you can tell whether there could be breaking changes in a new release.
- royjacobs 4y ago
  Exactly. Just having a date and some commit hash doesn't tell me anything.
lionkor 4y ago
But you dont get the most important part: Will installing the 2022.05.03-37492af update break my build or not? 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. 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. Cute idea, but appending a git commit hash to the end of a semantic version may be more useful than any of this.
- lionkor 4y ago
  Plus, if your main issue with semantic versioning is that you cant find your changelog, make it part of your git repo. At BeamMP (a multiplayer game project) we have a changelog.md file right in the server repo. Go to any release tag and youll automatically also have the relevant changelogs.
- nathanaldensr 4y ago
  I agree. Additionally, some binaries like .NET assemblies have "informational" versions that can be set to arbitrary strings. I like to version my assemblies something like 1.2.3.4-rc.1+githash to communicate not only the semantic version but also the commit hash used during the build.
rtpg 4y ago
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 This basically doesn’t matter though, and is easy, and avoids most ordering questions as well that come with CI. Highly recommend, and at least think semver is silly for versioning applications in general (libs are different of course)
welder 4y ago
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. 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. You get all those "Pros" by working within Semver and appending the date to the patch part: major.minor.patchyearmonthday Edit: To support version parsers always expecting only 3 version numbers I removed the dashes in the example.
- ricardobeat 4y ago
  Appending date breaks a ton of naive version parsers.
  - welder 4y ago
    Then just use: major.minor.patchyearmonthday which would work for naive version parsers that always expect 3 numbers separated by dots.
    - deleted 4y ago
      [deleted]
bin_bash 4y ago
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.
jph 4y ago
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. The purpose is to enable APIs and build tools to work well, such as package manager project files that specify a version. To answer the author's questions: "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. "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. "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. "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. "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.
- ricardobeat 4y ago
  The author seems to be focusing on applications. If you’re releasing an app, service or anything else that doesn’t expose a public API, there is no point in having those compatibility semantics.
  - jph 4y ago
    If you're releasing an app that our teams are using, then yes please use semver, because we manage apps via system package managers (e.g. macOS brew, Windows wpm, Ubuntu apt, etc.) and containers (e.g. Docker, Podman, etc.), and infrastructure as code (e.g. Ansible, Packer, etc.). This enables our systems to automate our application updates. We do PATCH updates continuously (e.g each night), MINOR updates during system downtime (e.g. each weekend), and MAJOR updates with manual scheduling when we can look at the changelogs. If you're not managing your systems' applications with package managers or containers or infrastructure as code, then IMHO these are well worth a look.
kmlx 4y ago
i’ll answer some questions from the article based on my own experience: > When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly? patches mean small bug fixes or improvements that don’t break the api. > Can you tell me when version 1.2.1 was released? Was it yesterday? Last year? Ten years ago? 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. > What is your company/team's meaning behind a major, minor, and patch increment? patch - small changes, no api changes minor - medium changes, no api changes major - big changes, api changes > Who decides when a new major version is released? Is it a person? Maybe it's based on the size of an architectural change? no, it’s if the api changes. > What happens to the version where the manager or developer forgot to put together a change log? we use git’s history for this.
aloisdg 4y ago
So CalVer with a git code basically? https://calver.org/ https://calver.org/
- chrismorgan 4y ago
  But please don’t use CalVer’s so-called “standard terminology”, because having “MM” be 1–12 and “0M” 01–12 (and the same for D and mostly Y) is ridiculous, flying in the face of the extremely well-established society-wide convention that “MM” means 01–12, and “M” 1–12. (Because of this folly, I firmly decline to cite CalVer in anything about date-based version numbers. It’s an obvious enough scheme anyway and doesn’t need a fancy name or specificationy sort of thing.)
vr46 4y ago
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? Also how do you tell between types of change? Major? Minor? Patch?
lllr_finger 4y ago
"When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?" Especially if you're using something like fzf that can easily search your command history, "every time someone has asked": git log <tag 1>..<tag 2> --pretty=oneline
the_common_man 4y ago
Seems to have misunderstood the point of semver
arnvald 4y ago
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. 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.
keithnz 4y ago
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" 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. 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.
ChrisMarshallNY 4y ago
> Possible Cons: > - Multiple builds on the same day? You would need access to the git repo to figure out which came first. > - Customers now have visibility into the last time their software was updated. - If corporations like Apple don't support it, the whole thing goes down the drain. - I know this seems crazy, but I have met people that don't use Git for version control.
- sidlls 4y ago
  I have a secret heresy, in that I still prefer older systems like Perforce and even svn or, horror of horrors, cvs. I’m a bit of a dinosaur I guess.
deleted 4y ago
[deleted]
nathanaldensr 4y ago
Not all version storage mechanisms support non-numeric components. For example, Windows executables' file version values can only be up to four dotted number components whose values cannot exceed 65535.
smitty1e 4y ago
If the package manager for the system lacks sufficient information regarding any system component, that would seem grounds for switching to a different OS.
JohnHaugeland 4y ago
"What do you mean builds aren't temporally linear?"
gardenhedge 4y ago
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. 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.
Patrol8394 4y ago
I prefer build number and git hash. You don’t need a date, you just need to know which one comes first without having to check git.
loloquwowndueo 4y ago
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.
tailspin2019 4y ago
Many of the disagreements in the comments seem to be overly focussed on versioning for installable software and dependencies (for example packages) where, I would agree, semantic versioning is still useful. Not all software is a dependency though, and not all software is installed by end users. The approach in this article is fine for hosted apps, or anything that's at the top of the dependency chain. EDIT: That said, this scheme is missing a sortable 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): 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) Metadata: 344 = Unique build number 9c88541 = Git hash 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. 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. 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. 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): Eg. versions, in order of most recent, still sortable across versioning format change: 2022.45.11+344.9c88541 2022.44.3+333.8b77462 2.1.0+303.1a65a73 2.0.3+297.3c878d2 Or without metadata: 2022.45.11 2022.44.3 2.1.0 2.0.3
hk1337 4y ago
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.
throw0101a 4y ago
How does one release/run two parallel branches at once? 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.
curling_grad 4y ago
This seems problematic when a project have "regular" and LTS releases. (such as node.js)
sam_lowry_ 4y ago
If only he offered versions like 2021.03.22-rd31d336 instead of 2021.03.22.d31d336, they would be semver-compatible while keeping all the benefits he is talking about.
namuol 4y ago
SemVer allows for near-arbitrary version suffixes which can convey info like date and hash, so nothing should stop you from using both versioning conventions together.
shawkinaw 4y ago
Hard to take seriously when the cons list doesn’t even have “versions no longer indicate breaking changes”.
dreamcompiler 4y ago
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. And btw the word "inherit" in the first sentence should be "inherent."
isitmadeofglass 4y ago
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? Yea, nah
twobitshifter 4y ago
Semantic versioning is public facing, but you’d still want to maintain a simple increasing build number of versioning.

32 points by jeremylevy 4y ago

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.

blowski 4y ago

Isn’t the “semantic” part of semantic versioning that you can tell whether there could be breaking changes in a new release.

royjacobs 4y ago
Exactly. Just having a date and some commit hash doesn't tell me anything.

lionkor 4y ago

But you dont get the most important part: Will installing the 2022.05.03-37492af update break my build or not? 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. 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. Cute idea, but appending a git commit hash to the end of a semantic version may be more useful than any of this.

lionkor 4y ago
Plus, if your main issue with semantic versioning is that you cant find your changelog, make it part of your git repo. At BeamMP (a multiplayer game project) we have a changelog.md file right in the server repo. Go to any release tag and youll automatically also have the relevant changelogs.
nathanaldensr 4y ago
I agree. Additionally, some binaries like .NET assemblies have "informational" versions that can be set to arbitrary strings. I like to version my assemblies something like 1.2.3.4-rc.1+githash to communicate not only the semantic version but also the commit hash used during the build.

rtpg 4y ago

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 This basically doesn’t matter though, and is easy, and avoids most ordering questions as well that come with CI. Highly recommend, and at least think semver is silly for versioning applications in general (libs are different of course)

welder 4y ago

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. 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. You get all those "Pros" by working within Semver and appending the date to the patch part: major.minor.patchyearmonthday Edit: To support version parsers always expecting only 3 version numbers I removed the dashes in the example.

ricardobeat 4y ago
Appending date breaks a ton of naive version parsers.
- welder 4y ago
  Then just use: major.minor.patchyearmonthday which would work for naive version parsers that always expect 3 numbers separated by dots.
  - deleted 4y ago
    [deleted]

bin_bash 4y ago

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.

jph 4y ago

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. The purpose is to enable APIs and build tools to work well, such as package manager project files that specify a version. To answer the author's questions: "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. "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. "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. "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. "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.

ricardobeat 4y ago
The author seems to be focusing on applications. If you’re releasing an app, service or anything else that doesn’t expose a public API, there is no point in having those compatibility semantics.
- jph 4y ago
  If you're releasing an app that our teams are using, then yes please use semver, because we manage apps via system package managers (e.g. macOS brew, Windows wpm, Ubuntu apt, etc.) and containers (e.g. Docker, Podman, etc.), and infrastructure as code (e.g. Ansible, Packer, etc.). This enables our systems to automate our application updates. We do PATCH updates continuously (e.g each night), MINOR updates during system downtime (e.g. each weekend), and MAJOR updates with manual scheduling when we can look at the changelogs. If you're not managing your systems' applications with package managers or containers or infrastructure as code, then IMHO these are well worth a look.

kmlx 4y ago

i’ll answer some questions from the article based on my own experience: > When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly? patches mean small bug fixes or improvements that don’t break the api. > Can you tell me when version 1.2.1 was released? Was it yesterday? Last year? Ten years ago? 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. > What is your company/team's meaning behind a major, minor, and patch increment? patch - small changes, no api changes minor - medium changes, no api changes major - big changes, api changes > Who decides when a new major version is released? Is it a person? Maybe it's based on the size of an architectural change? no, it’s if the api changes. > What happens to the version where the manager or developer forgot to put together a change log? we use git’s history for this.

aloisdg 4y ago

So CalVer with a git code basically? https://calver.org/ https://calver.org/

chrismorgan 4y ago
But please don’t use CalVer’s so-called “standard terminology”, because having “MM” be 1–12 and “0M” 01–12 (and the same for D and mostly Y) is ridiculous, flying in the face of the extremely well-established society-wide convention that “MM” means 01–12, and “M” 1–12. (Because of this folly, I firmly decline to cite CalVer in anything about date-based version numbers. It’s an obvious enough scheme anyway and doesn’t need a fancy name or specificationy sort of thing.)

vr46 4y ago

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? Also how do you tell between types of change? Major? Minor? Patch?

lllr_finger 4y ago

"When was the last time you could tell someone the difference between version 1.2.1 and 1.2.3 quickly?" Especially if you're using something like fzf that can easily search your command history, "every time someone has asked": git log <tag 1>..<tag 2> --pretty=oneline

the_common_man 4y ago

Seems to have misunderstood the point of semver

arnvald 4y ago

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. 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.

keithnz 4y ago

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" 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. 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.

ChrisMarshallNY 4y ago

> Possible Cons: > - Multiple builds on the same day? You would need access to the git repo to figure out which came first. > - Customers now have visibility into the last time their software was updated. - If corporations like Apple don't support it, the whole thing goes down the drain. - I know this seems crazy, but I have met people that don't use Git for version control.

sidlls 4y ago
I have a secret heresy, in that I still prefer older systems like Perforce and even svn or, horror of horrors, cvs. I’m a bit of a dinosaur I guess.

deleted 4y ago

[deleted]

nathanaldensr 4y ago

Not all version storage mechanisms support non-numeric components. For example, Windows executables' file version values can only be up to four dotted number components whose values cannot exceed 65535.

smitty1e 4y ago

If the package manager for the system lacks sufficient information regarding any system component, that would seem grounds for switching to a different OS.

JohnHaugeland 4y ago

"What do you mean builds aren't temporally linear?"

gardenhedge 4y ago

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. 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.

Patrol8394 4y ago

I prefer build number and git hash. You don’t need a date, you just need to know which one comes first without having to check git.

loloquwowndueo 4y ago

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.

tailspin2019 4y ago

Many of the disagreements in the comments seem to be overly focussed on versioning for installable software and dependencies (for example packages) where, I would agree, semantic versioning is still useful. Not all software is a dependency though, and not all software is installed by end users. The approach in this article is fine for hosted apps, or anything that's at the top of the dependency chain. EDIT: That said, this scheme is missing a sortable 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): 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) Metadata: 344 = Unique build number 9c88541 = Git hash 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. 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. 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. 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): Eg. versions, in order of most recent, still sortable across versioning format change: 2022.45.11+344.9c88541 2022.44.3+333.8b77462 2.1.0+303.1a65a73 2.0.3+297.3c878d2 Or without metadata: 2022.45.11 2022.44.3 2.1.0 2.0.3

hk1337 4y ago

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.

throw0101a 4y ago

How does one release/run two parallel branches at once? 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.

curling_grad 4y ago

This seems problematic when a project have "regular" and LTS releases. (such as node.js)

sam_lowry_ 4y ago

If only he offered versions like 2021.03.22-rd31d336 instead of 2021.03.22.d31d336, they would be semver-compatible while keeping all the benefits he is talking about.

namuol 4y ago

SemVer allows for near-arbitrary version suffixes which can convey info like date and hash, so nothing should stop you from using both versioning conventions together.

shawkinaw 4y ago

Hard to take seriously when the cons list doesn’t even have “versions no longer indicate breaking changes”.

dreamcompiler 4y ago

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. And btw the word "inherit" in the first sentence should be "inherent."

isitmadeofglass 4y ago

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? Yea, nah

twobitshifter 4y ago

Semantic versioning is public facing, but you’d still want to maintain a simple increasing build number of versioning.