The example I gave on the site with "UI and implementation" branches could work. I haven't done this in practice so I cannot confirm.

Idk how you'd be able to tell anything about a commit from its hash tbh.

You're right though, I primarily create/work on SaaS products and this versioning is perfect for it.

I think my original reply was a little brusque. Really this is a fine scheme, but I do think it's limited in where it can realistically be used - IMO, small self-contained SaaS products only - and I do think that the hash should be called out explicitly as metadata vs. an integral part of the version.

Simply moving from YEAR.MONTH.DAY.CHANGE_ID to YEAR.MONTH.DAY.UPDATE.CHANGE_ID, with UPDATE being a mandatory monotonically-increasing integer, would make this scheme more attractive to a wider variety of users.

When version 1 receives an update, that's how we got version 2. The update to version 2 is version 3.

I don't see what is here to misunderstand.

If someone wants to take just a subset of the changes between 2 and 3 (say just one fix) and backport it over version 1, they are on their own.

That's a downstream problem that the project doesn't have to cater to in its versioning scheme. The project issued a bugfix, and that bugfix was applied when version 2 was superseded with 3; end of story.

The problem with this is that it is not practical. One example I can think of on the spot is an old tool written to support Windows 7, a bridge version supporting win 7-10 and a new version supporting only 10. Most industries do not move at the same pace (We have some projects that can only run on Windows 95). So some security updates to the bridge version adn the new version are made simultaneosly and corresponding update to their version numbers.

Another example is python 2 and python 3, where python 2 was getting updates form 5+ years after python 3 released.

Python 2 and Python 3 are different languages that get installed side by side.

Two completely independently developed C compilers, or independent implementations of Common Lisp are much more compatible with each other than are Python 2 and Python 3.

They could as well have different names (think Perl vs. Rakudo).

Racket is more compatible with Scheme than Python 3 is with Python 2, yet has a different name, for good reasons.

Both Python 2 and Python 3 could respectively use a simple versioning numbering scheme. Python 3 version 1, version 2, version 3, ...

The problem was not with a random someone wanting to make a change to version 1, it was with the project wanting to make a change to version 1. That is not a downstream problem.