I think this is a nice way to clarify the different use cases for version numbers:

- SemVer is a communication tool for when an author needs to tell a potential user what to expect from a new version.

- TrunkVer is an auditing/engineering tool for when you need to give a unique identifier to a version for technical reasons.

I think this page is a nice codification of a useful practice, but it does itself a disservice by positioning itself against SemVar and claiming to be a "drop-in" replacement.

I’ve been happily using date base version numbers in any user facing product (e.g apps) for a while now. It’s been great.

While semver makes great sense on paper, and even allows nifty little algebras in dependency declarations, it is been my experience that the delineations are not always as easy to decode and different team members can quibble over the exact realization of the boundaries.

Furthermore, it’s very much been my experience that semver changes, like all code comments, only communicate the intent of the developer and not always the reality. A minor roll may be anticipated as backwards compatible, until an unrealized use case pops up and makes the minor change very breaking.

In what way is this „SemVer-compatible“ when you just ignore the „Major increment <=> breaking changes“ convention? It has 3 numbers separated by dots? This just increments major version every time a build is started, even though there might not be breaking changes.

Edit: When looking at the SemVer page: https://semver.org/#if-even-the-tiniest-backward-incompatibl...

The formal spec technically only tells you that you MUST increment Major for breaking changes, and not that you can’t do it every time, but the FAQ makes it clear what the spirit of the rule is. I can’t see how TrunkVer can be called SemVer compatible with this construction method.

The EBNF in the page does not match the textual description:

    - "ALPHANUMERIC" is only letters, not numbers
    - "BUILD_REF" can contain dashes/hyphens "-"
    - "GIT_COMMIT_REF" is the letter "g" and a single hex character
    - "BUILD_REF" and "SOURCE_REF" may be empty, since they are 0 or more repetitions
    - "TIMESTAMP" is arbitrary numbers, so month or hour may be "99" for example

A sequential build/release number would suffice in many cases.

If the thing you're shipping isn't meant to be a dependency for other projects, then semantic versioning doesn't really fit.

In trunkver though, using the timestamp of the build time is a little weird, since you could inadvertently end up building an earlier version of trunk at a later time.

Putting an identifier of the job that built the release in the version number also seems heavy for what could just be an entry in a log file for when you need those forensics.

Another (simpler) versioning "standard" using calendar-based versioning: https://calver.org

I've been using something like this for the Unity game I'm working on where I need regular updates. However, I don't think it let me use 14 numbers in the major field. So I've stuck with something along the lines of <year>.<month>.<date>-<hours*60+minutes> to better saturate. It's nice to know there's a standard for this though.

What if the CI vendor decides to use the same for its ids? Then you have even longer version numbers.

And if CI vendors aren't expected to adopt this, why expect a lot of devs to?

On my computer, the CI version ID wraps, because between the other parts of the version and the padding, there isn't enough space. I think that says something about the length of the version identifier.

I can see using this if what you're building is at the end of the supply chain, and there is really less need to make the claims that SemVer does. Conversely, if you have downstream consumers, I can't imagine taking away the compatibility statements in SemVer.

Git commit sha produces a good enough version for most software.

> If the source reference is a git commit checksum, it may be truncated to 7 characters (--short)

Doesn't the length of shortened git hashes depend on the size of the repo (whether or not shortened hashes of a given length collide)?

Here's the thing about versions: they are never "complete", Because you never have just one version.

Whatever you are looking at is most likely an amalgam of many different things, which all have their own versions. Your one perfect holy version number does not tell you those versions, so you have to look them up at some point (you did save the versions of all your dependencies and pack them into a BOM, right?).

This trunk version similarly does not encode all the information you need. And what is it going to be used for? A python package? Every python package? A docker container? What about all the versions of stuff in that container? What about the helm chart that will ship this container, what's it's version? What about the version of all your helm charts that have been tested as working in stage before shipping them to prod?

If you're going to have a "generic incremented trunk version", just make it a plain-old continuously incrementing integer (or hex, or whatever) with no semver. Because you're going to have to look up more information about what's inside it later anyway, and everything's going to have its own version as you modify individual items.

Packing all this extra information in is actually counter-productive, because it's now much longer and more complex (which makes it harder to just compare a list side by side), yet it doesn't give you enough info. Ok, datestamp; where's the timezone? Ok, git sha; which repo (and has history been rewritten, or the files moved to a different repo)? Ok, CI build number; which build system (if you have multiple, or you moved from one to another)?

Maybe some of it you can intuit, but eventually you'll wish it was different again. Might as well just make it a plain integer you can pass to a script that dumps out everything related to it.

Semver's primary use case is not identifying what's inside or where it came from. The numbers are little more than a simple incrementor, and the use case is just a user who wants to know how afraid they should be. It's intended solely to communicate how likely this thing is to fuck your shit up. If it's a major version change, here be dragons. If it's minor, be cautious. If it's a patch, it should be harmless. Semver is a threat indicator. And it's easy to work with because it's so simple; comparing versions is easy. Comparing a wall of these TrunkVers will be like staring at The Matrix code.

(SemVer's supposed to tell you what dependencies it can work with (>major, >major.minor, etc), but you still need the entire dependency DAG to have a pair of package name and version in order to make sense of it; you could do the exact same thing with a list of names and simple integers (foo >= 23456, foo<1234); now imagine with this TrunkVer (foo >= 20241127214906.0.0-g1f8292a-12058740477-1)...)

Great, now sell this to your marketing department

I much prefer Nerdbank Git Versioning (NBGV): https://github.com/dotnet/Nerdbank.GitVersioning

It allows repeatable builds because it uses the "git height" as the increment source.

This is an implicitly updated value that is centrally coordinated, but isn't a separate system. If you have Git, you have a Git commit history, and hence an incrementing counter.

NBGV can stamp binary outputs such as .NET EXEs and DLLs, generates compile-time sources with version strings, works with Node.js projects as well, and integrates with Azure DevOps pipelines automatically.

This breaks efficient dependencies resolution. SemVer is called that because versions carry semantic meaning, TrunkVer appears no better than using UUIDs for each version name. You know nothing of the relation between two versions in this scheme, other than which came first.

Add a metalayer to turn version names into memorable word phrases imo lol.

And the best part is you can completely disregard the need to maintain backwards compatibility, because every build implies a breaking change! /s

Is what?