[seanhunter]

Or just use ISO8601-formatted dates as versions and derive huge benefits.

1. version numbers sort numerically and lexicographically in a sensible way, including across projects and packages which use the same format

2. users get educated that these preciously-held ideas they have about software version numbers are complete superstition. Like "something with a zero major number means not production ready", "something with a zero minor number means I should wait until there's a patch", "something with a major number increase means backwards-incompatible", "something with a minor number increase means backwards-compatible"

3. You know when a particular version (of everything) came out. "We started seeing a wierd bug on X date" no longer is impossible to figure out.

[tom_]

I've done this for personal projects for years, for exactly the reasons you state - other than user re-education, my projects don't have enough users to make an impact. For GitHub releases, I get the CI script to do ``git log -1 --format=%cd-%h --date=format:%Y%m%d-%H%M%S'' (producing output along the lines of "20230708-150500-1234567") and use that as the suffix. (Add a -prerelease suffix on if it's coming from a non-default branch.) This sorts nicely and saves me 2 minutes if I need to find the commit in the history.

(These are self-contained projects. I suppose semver does make some sense for libraries that you link with.)

Professionally, it's been 99% Perforce for about 15 years, so it's routine to use the submitted changelist number, submitted changelists being numbered in the order they were subsequently committed. Sadly not fixed-width, but at least Explorer sorts them sensibly.

Two difficulties I have had doing this with git:

- there doesn't seem to be a way to get git to enforce UTC, so the dates are in my local time zone (for my projects this is not really an issue, and my timezone is almost UTC anyway)

- the CI system runs separate builds for different targets, and using the git commit timestamp ensures all builds get the same time stamp. But it's then possible to end up with timestamps significantly different from the actual release time, or (worse) out of order. I could probably do something better about this than my current "solution" of doing nothing, but this has only happened a couple of times

[zajio1am]

That only works for software with simple linear versioning. If i have two major versions (say 2 and 3), i could still release a minor version to the older major version (so i would release 2.8, then 3.0, then 2.9, then 3.1).

[xigoi]

When working with versioning software that requires a version in the format A.B.C, I like to use YYYY.MMDD.N, where N is the number of versions already released on that day.