>Which is exactly what TrunkVer does. Every release increases the major version number. As long as the clock you use for the timestamp is monotonic. Well that

>Which is exactly what TrunkVer does. Every release increases the major version number. As long as the clock you use for the timestamp is monotonic. Well that and you never need to run old versions of the software, rebuild old versions, deal with customers who have different versions, etc. >TrunkVer os useful in cases where knowing the time the version was created is more useful than knowing how many releases are between two versions. In particular, continuously deployed projects, where you might have multiple releases a day. If you want to know when a build happened then it would be better to put that last. SemVer-based package systems typically do something like that with a fourth number. However, odds are you just want the latest in a series based on one code archive, so it only needs to be a simple sequence. People who need to know the date can consult other metadata to find out. >For a library, I think it would be pretty rare for TrunkVer to make sense, unless maybe the only consumer of the library was an app that also used TrunkVer. I think it's more complicated than this and thus TrunkVer only makes sense at the top level. If you apply it to a library, you better own the library and practically use a monorepo for your one app. >For an app, it often makes sense to version an external API or data format independently of the app itself. This only makes sense if you have multiple apps to deal with. Otherwise, the data format version practically is the app version and it would be pointless extra work for them to deviate.