4 ms·

The best versioning is the one you already have and use every day. It is right under your nose. You probably typed or pasted one or these special version strin

The best versioning is the one you already have and use every day. It is right under your nose. You probably typed or pasted one or these special version strings in today or you will later. Or you sent one to a colleague in a slack message this week most certainly. It is of course the git commit hash! Suck all meaning out of your version by using the commit hash. Never worry about which digit to increment (semver, 0ver) or what date it is (calver) because who remembers the date. Also has the advantage that it’s easy to check out the source code for a version! Use git log and pipe that to a file in /var/www and you have release notes with the version numbers!

BiteCode_dev 5y ago
Really handy to communicate verbaly or promote.
- wraptile 5y ago
  You just keep appending spaces until commit hash sounds human! Check out latest release: h0rs35l0v3b4tt3ry4cid5! Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol
ricardobeat 5y ago
And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.
choeger 5y ago
If that's not sarcasm, and I am really not sure whether it is, just one counter argument: commit hashs are not ordered and they can change.
- account42 5y ago
  > they can change This is incorrect. You can create a new commit with a different hash, but the commit hash being a checksum of the commit contents will never change for the same commit.
  - Sebb767 5y ago
    > the commit hash being a checksum of the commit contents will never change for the same commit It will if the parent changes, for example on a rebase. Now, it is up to discussion on whether that is a different commit (technically the parent hash is part of the commit), but most people probably consider the content changes to be the actual commit.
    - deleted 5y ago
      [deleted]
    - account42 5y ago
      Then most people are wrong. We already have a word for the content changes: a patch. A commit is a patch applied on a previous state. (Or for git, a snapshot with zero or more previous states if you want to be pedantic.)
      - Sebb767 5y ago
        If you google what is a git commit, almost nobody points this specialty out. This is also most likely what the above comment got wrong. So I don't disagree with you; if we're being pedantic, the commit hash never changes for the same commit [0]. I just pointed out that what someone without an in-depth knowledge of git would intuitively consider to be a commit can indeed have changing hashes. [0] There does not seem to be an authoritative definition for the git-type of commit, so I guess we need to go with "a commit is what git considers a commit".
izzytcp 5y ago
No no, you have a point, gotta agree. I have my own project and I always know which is my latest version, it is: a11bef06a3f659402fe7563abf99ad00de2209e6 edit 1: (sorry wrong one) 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 edit 2: (ahh, sorry again, this is my latest version) a11bef06a3f659402fe7563abf99ad00de2209e6 edit 3: (this is the one, definitely) ca82a6dff817ec66f44342007202690a93763949
- jraph 5y ago
  Too complicated, just generate a UUID.
GerryLefaux 5y ago
I find git commit hash too long for no good reason. I prefer to version with the file size, which is strictly increasing if you follow those best practices: - never delete any of your valuable code (commenting out is OK) - never break up code into several files (makes it simpler to read).
- ModernMech 5y ago
  > - never delete any of your valuable code (commenting out is OK) So how does this work if you want to change a line in a function? Do you just comment out the line and write a new version below it? i.e. if I want to fix a bug in my code, I can't just fix it, I have to add a line of code to my program. How does this system work in practice? The way I code, it seems like this would lead to a huge file that is mostly commented.
  - maple3142 5y ago
    I think it is meant to be a joke like ZeroVer.
  - Scarblac 5y ago
    You change the line, and add a comment explaining what the code used to do?
    - quickthrower2 5y ago
      This, or add another cat photo to assets
- da_big_ghey 5y ago
  I hope you are making a joke, if not, you will be overjoyed when you find a source control system and can tidy your source file.
lucideer 5y ago
> Never worry about which digit to increment (denver, 0ver) Yay, every version is a patch and who cares if there's breaking changes. So now I need full QA before I pull in every security patch: a lovely idea in theory but in practice it's just a major motivator for engineers to leave their dependency tree to grow horribly out of date and littered with known vulns. > ... or what date it is (calver) because who remembers the date. Have to agree with this though, calver is pointless. All it does is caters to the general bias people have toward "new is better" and "well maintained = frequently added new features", neither of which are true.
- rubyist5eva 5y ago
  > who cares if there's breaking changes. Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. Anecdote: Just yesterday our entire CI process was taken down due to a bump in the AWS ebcli package from 3.20.0 -> 3.20.1. This should have been a non-breaking change, but instead resulted in an entire days worth of release management being grinded to a halt. Pin your versions. Test all upgrades.
  - lucideer 5y ago
    An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection). Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.
    - rubyist5eva 5y ago
      The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away. Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should. Be thoughtful. Methodical. Consistent.
simias 5y ago
That's missing the point of release versions. Git commits are not obviously ordered (you need access to the repo to do this), they don't tell you if it's a small patch release or a huge change. Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.
jpxw 5y ago
Perhaps this is a joke I’m not getting in which case I apologise. The advantage of semantic versioning (SemVer) over git hashes is… well… semantics. You can immediately identify if the next version introduces a breaking change, for instance. This without mentioning ordering, and being easily able to tell versions apart - e.g: which (if any) versions are different in these three versions? c26cf8af138955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfe9a6f9532680b963628 You can get easy check-outs and git-logs by using git tags for each version.
chrismorgan 5y ago
Some useful commands for making this more friendly: Get the number of commits with `git rev-list --count HEAD`. Get a label that uses the most recent tag plus the number of commits since and the current commit hash with `git describe` (read its documentation, it’s got a few nice knobs to match whether you use unannotated tags, annotated tags, branches, &c.). This sort of thing is used in Arch Linux packages based on Git repositories, things like this: pkgver () { cd the-git-repository git describe --long 2>/dev/null | sed 's/$[^-]*-g$/r\1/;s/-/./g' || \ printf "r%s.g%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" } … which will give you versions like “1.2.3.r45.gdeadbeef” for commit deadbeef which is 45 commits past the one tagged 1.2.3, or “1.2.3.r0.g01234567” for commit 01234567 which is tagged 1.2.3, or “r1234.gdeadbeef” where you have no tags and 1234 commits from the root(s) until HEAD which is at commit deadbeef.
smsm42 5y ago
Versioning scheme without an ordering is usually pretty bad idea. Also, try telling your colleague which version she needs to install... Might as well give up on communicating by anything but Slack.

BiteCode_dev 5y ago

Really handy to communicate verbaly or promote.

wraptile 5y ago
You just keep appending spaces until commit hash sounds human! Check out latest release: h0rs35l0v3b4tt3ry4cid5! Eventually people will start random commits like "random commit to change hash" when commits accidently result in racist or taboo terms lol

ricardobeat 5y ago

And have no idea how recent the version is unless you have immediate access to git. It’s a very engineer-centric idea.

choeger 5y ago

If that's not sarcasm, and I am really not sure whether it is, just one counter argument: commit hashs are not ordered and they can change.

account42 5y ago
> they can change This is incorrect. You can create a new commit with a different hash, but the commit hash being a checksum of the commit contents will never change for the same commit.
- Sebb767 5y ago
  > the commit hash being a checksum of the commit contents will never change for the same commit It will if the parent changes, for example on a rebase. Now, it is up to discussion on whether that is a different commit (technically the parent hash is part of the commit), but most people probably consider the content changes to be the actual commit.
  - deleted 5y ago
    [deleted]
  - account42 5y ago
    Then most people are wrong. We already have a word for the content changes: a patch. A commit is a patch applied on a previous state. (Or for git, a snapshot with zero or more previous states if you want to be pedantic.)
    - Sebb767 5y ago
      If you google what is a git commit, almost nobody points this specialty out. This is also most likely what the above comment got wrong. So I don't disagree with you; if we're being pedantic, the commit hash never changes for the same commit [0]. I just pointed out that what someone without an in-depth knowledge of git would intuitively consider to be a commit can indeed have changing hashes. [0] There does not seem to be an authoritative definition for the git-type of commit, so I guess we need to go with "a commit is what git considers a commit".

izzytcp 5y ago

No no, you have a point, gotta agree. I have my own project and I always know which is my latest version, it is: a11bef06a3f659402fe7563abf99ad00de2209e6 edit 1: (sorry wrong one) 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 edit 2: (ahh, sorry again, this is my latest version) a11bef06a3f659402fe7563abf99ad00de2209e6 edit 3: (this is the one, definitely) ca82a6dff817ec66f44342007202690a93763949

jraph 5y ago
Too complicated, just generate a UUID.

GerryLefaux 5y ago

I find git commit hash too long for no good reason. I prefer to version with the file size, which is strictly increasing if you follow those best practices: - never delete any of your valuable code (commenting out is OK) - never break up code into several files (makes it simpler to read).

ModernMech 5y ago
> - never delete any of your valuable code (commenting out is OK) So how does this work if you want to change a line in a function? Do you just comment out the line and write a new version below it? i.e. if I want to fix a bug in my code, I can't just fix it, I have to add a line of code to my program. How does this system work in practice? The way I code, it seems like this would lead to a huge file that is mostly commented.
- maple3142 5y ago
  I think it is meant to be a joke like ZeroVer.
- Scarblac 5y ago
  You change the line, and add a comment explaining what the code used to do?
  - quickthrower2 5y ago
    This, or add another cat photo to assets
da_big_ghey 5y ago
I hope you are making a joke, if not, you will be overjoyed when you find a source control system and can tidy your source file.

lucideer 5y ago

> Never worry about which digit to increment (denver, 0ver) Yay, every version is a patch and who cares if there's breaking changes. So now I need full QA before I pull in every security patch: a lovely idea in theory but in practice it's just a major motivator for engineers to leave their dependency tree to grow horribly out of date and littered with known vulns. > ... or what date it is (calver) because who remembers the date. Have to agree with this though, calver is pointless. All it does is caters to the general bias people have toward "new is better" and "well maintained = frequently added new features", neither of which are true.

rubyist5eva 5y ago
> who cares if there's breaking changes. Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. Anecdote: Just yesterday our entire CI process was taken down due to a bump in the AWS ebcli package from 3.20.0 -> 3.20.1. This should have been a non-breaking change, but instead resulted in an entire days worth of release management being grinded to a halt. Pin your versions. Test all upgrades.
- lucideer 5y ago
  An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection). Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.
  - rubyist5eva 5y ago
    The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away. Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should. Be thoughtful. Methodical. Consistent.

simias 5y ago

That's missing the point of release versions. Git commits are not obviously ordered (you need access to the repo to do this), they don't tell you if it's a small patch release or a huge change. Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.

jpxw 5y ago

Perhaps this is a joke I’m not getting in which case I apologise. The advantage of semantic versioning (SemVer) over git hashes is… well… semantics. You can immediately identify if the next version introduces a breaking change, for instance. This without mentioning ordering, and being easily able to tell versions apart - e.g: which (if any) versions are different in these three versions? c26cf8af138955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfea96f9532680b963628, c26cf8af130955c5c67cfe9a6f9532680b963628 You can get easy check-outs and git-logs by using git tags for each version.

chrismorgan 5y ago

Some useful commands for making this more friendly: Get the number of commits with `git rev-list --count HEAD`. Get a label that uses the most recent tag plus the number of commits since and the current commit hash with `git describe` (read its documentation, it’s got a few nice knobs to match whether you use unannotated tags, annotated tags, branches, &c.). This sort of thing is used in Arch Linux packages based on Git repositories, things like this: pkgver () { cd the-git-repository git describe --long 2>/dev/null | sed 's/$[^-]*-g$/r\1/;s/-/./g' || \ printf "r%s.g%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" } … which will give you versions like “1.2.3.r45.gdeadbeef” for commit deadbeef which is 45 commits past the one tagged 1.2.3, or “1.2.3.r0.g01234567” for commit 01234567 which is tagged 1.2.3, or “r1234.gdeadbeef” where you have no tags and 1234 commits from the root(s) until HEAD which is at commit deadbeef.

smsm42 5y ago

Versioning scheme without an ordering is usually pretty bad idea. Also, try telling your colleague which version she needs to install... Might as well give up on communicating by anything but Slack.