Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

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!

View on HN

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

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

I think it is meant to be a joke like ZeroVer.

You change the line, and add a comment explaining what the code used to do?

This, or add another cat photo to assets

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.

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

Too complicated, just generate a UUID.

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.

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.

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

Really handy to communicate verbaly or promote.

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

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.

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.

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

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

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.

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.

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

You are misunderstanding the scope of SemVer. It's purely about intentional changes to public interfaces. It should go without saying that no versioning scheme can ever hope to indicate whether or not new bugs have been introduced or uncovered that impact your consumer of said interface, nor can it possibly anticipate potential bugs in consumers that could be triggered by any changes that result in valid but previously unseen data being returned. It also doesn't say anything about the update process itself. If an update fails in such a way that your consumer can't use the interface that has nothing to do with the version number.

No one reasonable has ever claimed that SemVer could allow you to just YOLO your updates without testing. When implemented properly it provides a comfort level for updates that should give you an idea of how closely you should look at the changes being made and how they might impact whatever you have consuming that interface.

> Have to agree with this though, calver is pointless.

I've found calver useful for applications. It makes it clear how old the version you're running is. IntelliJ and Windows both use it and I prefer it to a version number you have to look up.

Yes actually, you're right. Arguments for semver aren't really applicable to user-facing stuff as upgrades there are tested by release teams and generally in most cases you want users to upgrade always.

The utopian ideal for apps in cases where someone might choose to use an older version (presuming LTS) would be somehow naming the release based on features, but that's not practical so date-based versioning is a really good proxy here.

Calver's uselessness only really applies to software dependencies.

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.

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

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

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

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

Reply on news.ycombinator.com